The Trusted Digital Web
Essays on Decentralization, Identity, and the Age of Agents
Selected and Synthesized Writings of Michael Herman Bindloss, Alberta, Canada — 2016–2026
Table of Contents
Models for Change: How Organizations and Societies Adopt New Technology
Thinking Tools: Definitions, Frameworks, and Digressions
A Life in Technology: Michael Herman
Inside Microsoft: History, Stories, and Lessons
Decentralization and the Economics of Platforms
Web 7.0: Vision and Founding Principles
Decentralized Identifiers and the DIDComm Architecture
DIDLibOS, AgenticOS, and the Trusted Digital Assistant
Parchment Programming: Designing Software for the AI Era
AILIES: Why AI Lies, and Who Is Accountable
AI Agents and the Future of Software Development
Digital Religion and the Post-Anthropocentric Era
Chapter 1: Models for Change: How Organizations and Societies Adopt New Technology
I have spent more than forty-five years watching technology get adopted, resisted, hyped, abandoned, and occasionally, genuinely absorbed into how people work and live. Somewhere along the way I started collecting the models that people use to explain that process — not because I set out to build a private taxonomy of change, but because no single model ever seemed to be enough. Crossing the Chasm explains why products stall between early adopters and the mainstream, but it says nothing about hype. The Gartner Hype Cycle explains hype, but it says nothing about how a society decides an idea is even thinkable. The Overton Window explains that, but it says nothing about what happens inside an individual’s head when they’re asked to change how they work. So I kept stacking models on top of each other, the way you’d overlay transparencies on an overhead projector, until patterns started to emerge that no single framework could show on its own.
This chapter is about that stack. It’s about the models I’ve built and borrowed over the decades to explain how change actually moves — through individuals, through organizations, through whole societies — and why I keep returning to them now that the change in question is decentralized identity, AI, and Web 7.0. If you want to understand why I’m convinced that AI adoption is currently spinning out of control, or why I think decentralization and centralization are really two ends of the same axis rather than opposing camps, you need to understand the models first. They’re not decoration. They’re the tools I think with.
A Comprehensive Guide, Because No Single Model Is Enough
At one point I sat down and documented more than twenty of the technology and change adoption models I’d encountered or built over my career — some of them famous, some of them mine, a few I didn’t even realize I’d been carrying around until I tried to write them down. I laid them out side by side, each one progressing left to right along an unspecified timeline, deliberately unanchored to a specific calendar so that they could be superimposed on each other.
That superimposition is the whole point. Geoffrey Moore’s Crossing the Chasm tells you that a technology has to survive a gap between early adopters and the early majority or it dies in the chasm. The Gartner Hype Cycle tells you that a technology goes through an Innovation Trigger, a Peak of Inflated Expectations, a Trough of Disillusionment, a Slope of Enlightenment, and finally a Plateau of Productivity. Neither of those, on its own, tells you when a technology becomes politically or socially acceptable to talk about — that’s the Overton Window’s job, and I found it useful enough that I built a version showing the Overton Window laid directly over the Technology Adoption Lifecycle, and another laid over ADKAR, and another compared against Treviño’s Six Degrees of Acceptance. Once you see that these frameworks are all describing the same underlying phenomenon from different angles — market economics, individual psychology, public discourse — you stop treating any one of them as the answer and start treating them as instruments in an orchestra.
Some of the other models in that catalog are more mundane and no less useful: the classic enterprise solution sales and adoption lifecycle, a “systems co-existence and migration” model for the unglamorous reality that old and new systems run in parallel for years, and Microsoft’s own “embrace, extend, and extinguish” pattern, which I include not because I admire it but because it is a genuinely predictive model of how a dominant incumbent absorbs a competing standard. I also kept Darrell O’Donnell’s exponential growth and exponential-hype-cycle variants, the CB-Insights NExTT framework, the Liedtka-Ogilvie design thinking model, and even a “three-letter words” model whose origin I’ve honestly lost track of — proof that useful frameworks accumulate from everywhere, not just from the canon. The point of assembling all twenty-plus of them in one place was never to declare a winner. It was to build a toolkit flexible enough that when a new wave of change showed up — blockchain, decentralized identity, large language models — I’d already have the right lens, or the right combination of lenses, ready to go.
Social Evolution: Change as Tribal History
The model I keep coming back to, the one that’s genuinely mine, is what I call Social Evolution. It grew out of a conversation about a wanderer — someone who leaves their tribe to share knowledge and wisdom with others, who later assembles a party of explorers to pursue a common set of goals, and who, further on, helps form a clan, then a band, then a tribe, then a full tribal society: a group of tribes organized around kinship. That’s not a metaphor I invented for technology; it’s a description of how human societies have always organized themselves, from a single person’s departure from the group all the way up to the formation of a nation state. What I noticed is that policies, procedures, processes, and technologies move through the exact same arc inside an organization. A single person breaks from convention with an idea. A small group forms around it. The group becomes a practice. The practice becomes policy. The policy becomes infrastructure everyone assumes was always there.
I documented this as a pair of companion diagrams — one showing Social Evolution as the creation of a nation state, tracing wanderer to explorer to clan to tribe to tribal society, and one showing Social Evolution’s defining principles, the underlying logic of why each stage has to happen before the next one can. Laid next to the standard Technology Adoption Lifecycle and ADKAR, the parallel is hard to miss: the “wanderer” is the innovator who has Awareness before anyone else does; the “clan” is the group that has developed Desire and Knowledge; the “tribe” is the organization that finally has the Ability to operationalize the idea; and the “tribal society” is what you get once Reinforcement has locked the change in as the new normal, indistinguishable from how things have always been done.
I didn’t design Social Evolution to be a partisan or political statement. It was a description of organizational and technological change. But models have a way of revealing more than you intended, and this one did.
The Self-Sovereignty Political Spectrum
Two years after I first published Social Evolution, I realized I had accidentally defined something else: a political spectrum. If you take the same axis — wanderer to explorer to clan to tribe to tribal society to nation state — and ask where power concentrates at each stage, you get a line running from true decentralization and self-sovereignty at one end to complete authoritarian centralization at the other. I called it the Self-Sovereignty Political Spectrum, and once I saw it, I couldn’t unsee it in every debate about digital identity, platform governance, and decentralization that I’ve had since.
I don’t think the model is dangerous, but I do think it’s clarifying, and clarifying models make people uncomfortable because they force a choice. So I’ll ask the question the model forces: what is your self-sovereignty political affiliation? Are you a decentralized, self-sovereign sheep who needs to be protected from concentrated power by default? Are you an authoritarian centralizationist wolf, content to consolidate control at the expense of everyone else in the flock? Or are you genuinely a centrist, someone who believes some centralization and some decentralization both have a place? I raise this not to score political points but because this exact axis — decentralization versus centralization — is the spine of nearly everything else in this book, from Web 7.0’s founding principles to the economics of platforms to the architecture of decentralized identifiers. Thomas Paine said the mind once enlightened cannot be darkened. Once you see the self-sovereignty spectrum underneath a debate about identity or platform control, you can’t unsee it either.
ADKAR and the Marriage of Individual and Social Change
Prosci’s ADKAR model — Awareness, Desire, Knowledge, Ability, Reinforcement — has been around for a long time as a way of describing how a single individual moves through change. What I wanted was a model that connected that individual journey to the larger social one, because in my experience organizational change fails not at the level of the org chart but at the level of the individual employee who never got past Awareness, or who has Desire but was never given the Knowledge to act on it. So I built Model 2d: Social Evolution, Driving Change (ADKAR) — mapping the wanderer-to-tribal-society arc directly onto the five ADKAR stages. The wanderer supplies Awareness. The explorers who join them supply Desire. The forming clan builds Knowledge. The tribe develops the Ability to actually execute. And the tribal society — the nation state, the fully adopted technology, the policy nobody questions anymore — is Reinforcement made permanent.
This mattering isn’t academic. Every large technology change I’ve been part of, from enterprise architecture initiatives to the current push for decentralized identity and Web 7.0, has died or succeeded at exactly these transition points. You can have brilliant technology and zero Desire. You can have Desire and no Knowledge of how to operationalize it. You can have Ability without Reinforcement, so the change reverts the moment attention moves elsewhere. Combining ADKAR with Social Evolution gave me a way to diagnose, at any point in a change effort, which stage was actually broken — the individual psychology or the social structure around it — instead of just declaring generically that “change is hard.”
The Wheel of Reincarnation, Then and Now
Not every pattern of change is a straight line from innovation to adoption. Some of it is a wheel. In 1968, T. H. Myer and I. E. Sutherland published a paper called “On the Design of Display Processors,” describing how their design process for early graphics hardware kept looping back on itself — architects would push functionality out to a peripheral device, then find themselves re-centralizing it, then pushing it back out again, and around and around. Their own words stuck with me: “It was not until we had traveled around the wheel several times that we realized what was happening.” That’s the Technology Wheel of Reincarnation — a cycle where an industry oscillates between centralizing and decentralizing the same capability, generation after generation, mainframe to minicomputer to PC to client-server to cloud to edge, mistaking each turn for a fresh insight when it’s really just another lap.
I bring this model back because I think we’re on the wheel again right now, and this time it’s spinning dangerously fast. I’ve said publicly that the AI Technology Wheel of Reincarnation is spinning so fast it’s going to fly apart, and that when it does, the damage won’t be contained to the companies at the center — it will hit everyone. What we’re watching with large-scale AI right now is the same centralize-decentralize-recentralize pattern that display processor architects lived through in the 1960s, except compressed from a design-review cadence into a news cycle, and with vastly more capital, computation, and dependency riding on each turn. Recognizing the wheel doesn’t stop it from turning. But it does mean I’m not surprised by each new lap, and it’s why I keep pushing, elsewhere in this book, for architectures — decentralized identifiers, self-sovereign identity, Web 7.0 — that are designed to survive the wheel’s next several revolutions rather than bet everything on wherever it happens to be pointing today.
The Overton Olive and MuDOO
The Overton Window — the range of ideas considered acceptable in public discourse at a given moment — is useful on its own, but I wanted a version that showed how that window itself evolves as an organization or society changes, not just what’s inside it at a single point in time. That became the Overton Olive: a digital-twin representation of progressive improvement through continuous transformation, built using the same graphitization approach I’ve used elsewhere to create digital twins of entire organizations. Think of it less as a static window and more as a shape you can rotate and watch deform as acceptance shifts — the olive’s long axis stretching or contracting as ideas move from unthinkable to radical to acceptable to popular to policy.
From there I built out a visual taxonomy of the Overton concept itself — a way of categorizing the different visual and conceptual forms the Overton Window takes when people try to adapt it for their own purposes — and finally the piece that ties this whole chapter together: the Multi-dimensional Overton Olive, or MuDOO, explicitly built as an ADKAR-enabled change management framework, MuDOO-ADKAR. This is where Social Evolution, ADKAR, and the Overton Window stop being three separate lenses and become one compound instrument. MuDOO-ADKAR lets you ask, for any proposed change: where does this sit in the window of what’s currently acceptable, and simultaneously, where does the population you’re trying to move sit on the Awareness-Desire-Knowledge-Ability-Reinforcement continuum? An idea can be inside the Overton Window and still fail because nobody has Ability. An idea can be outside the window entirely and still be worth pursuing if you’re playing a long enough game to shift Awareness first. Multi-dimensionality is the whole point — real change efforts are never single-axis problems, and a framework that only tracks acceptability, or only tracks individual readiness, will always miss half the picture.
The Modern 8-Sided Ecosystem Marketplace Model
The most recent addition to this toolkit extends the same instinct — that change happens inside a structure with more sides than people usually bother to draw — from organizations and societies to marketplaces. The Modern 8-Sided Ecosystem Marketplace Model maps out the eight distinct parties and force vectors that shape how a platform or ecosystem actually evolves, rather than the two- or three-sided market diagrams that dominate most platform economics writing. I built it because every time I looked at a real digital ecosystem — mobile app stores, identity networks, AI platforms — the standard two-sided marketplace model (buyers and sellers, or users and developers) was leaving out participants who had just as much power to accelerate or block change: infrastructure providers, regulators, standards bodies, competing platforms, and more. This model is the newest tool in the stack, and it’s the one I expect to get the most use out of in the chapters ahead on decentralization economics, where the question is never just who’s buying and who’s selling, but who actually controls the points where value and power concentrate.
Why This Matters
None of these models are complete on their own, and I don’t think any model ever will be. That’s not a weakness — it’s the reason I keep building and collecting them. Crossing the Chasm tells you about market timing. The Gartner Hype Cycle tells you about expectation management. The Overton Window and its Olive descendants tell you about the boundaries of acceptable discourse and how they shift. ADKAR tells you what has to happen inside a single human being before change sticks. Social Evolution tells you how that individual change scales up into tribes, organizations, and nation states — and, as it turns out, into a political spectrum running from self-sovereignty to authoritarian centralization. The Wheel of Reincarnation tells you that none of this is linear, that we’ve been here before, and that if you’re not careful you’ll mistake the next lap for genuine progress. And the 8-Sided Ecosystem Model tells you that the arena where all of this plays out has more players in it than the simple stories usually admit.
I open this book with these models because everything that follows — the case for decentralized identity, the argument for Web 7.0, the warnings about AI trust and accountability, the reading of Microsoft’s own history — is, underneath it all, an argument about change: whether it happens, how fast, who resists it, who it benefits, and whether we’re actually making progress or just going around the wheel one more time. I’ve spent forty-five years building the instruments to answer that question. The rest of this book is me using them.
Chapter 2: Thinking Tools: Definitions, Frameworks, and Digressions
Most of what I write about — Web 7.0, decentralized identifiers, trust graphs, AILIES — depends on a small set of habits of mind that I almost never explain directly, because I’m usually too busy using them. I define my terms obsessively. I try to reason up from bedrock rather than sideways from precedent. I distrust rooms where everyone agrees with everyone else. I notice when a story hasn’t found its audience yet, and I notice when it has. And on evenings when I’m not writing specifications, I still can’t turn the pattern-recognition off — I end up reading about the Renaissance, or the War of 1812, or chaos theory, and finding, almost against my will, that it rhymes with whatever I was thinking about that morning.
This chapter is the toolbox, not the machine. It’s where I keep the definitions, the frameworks, and the odd digressions that don’t belong to any one project but that show up, quietly, underneath everything else in this book. Some of these posts are working notes I wrote for myself and never expected anyone else to read twice. Others are closer to manifestos. Taken together, they’re a portrait of how I think before I start building.
A Taxonomist’s Toolkit: Words for Organizing Knowledge
I’ve spent a career caring more than most people about the difference between a taxonomy and an ontology, and I make no apology for it. Sloppy vocabulary produces sloppy architecture. If you can’t tell me precisely what kind of structure you’re building, you probably haven’t decided yet — you’re just accumulating terms and hoping a pattern will announce itself.
So here is the glossary I keep coming back to, in ascending order of structural complexity:
A Controlled Vocabulary is simply a list of distinct, selected terms or keywords — nothing more. A Dictionary or Glossary is a vocabulary with definitions attached. A Grammar is a set of structural rules governing how clauses, phrases, and words can be composed in a given language — it governs arrangement, not meaning. A Taxonomy takes terms from a vocabulary, dictionary, or glossary and organizes them by a classification system, most often hierarchical, though hierarchy isn’t a strict requirement. A Folksonomy is what you get when those same terms are categorized not by an authority but by a crowd — a set of users’ tags or keywords, bottom-up rather than top-down. And an Ontology, a Semantic Network, or a Knowledge Graph is a superset of everything above: it adds properties (with or without data types) and potentially arbitrary interrelationships between terms. It’s a set of types, properties, and relationships, full stop — the richest structure in the family, and the one most people reach for before they’ve earned it.
I care about this ladder because I watch people skip rungs constantly. They call a spreadsheet of tags an “ontology.” They call a folksonomy a “taxonomy” because it has a pretty diagram. Precision here isn’t pedantry — it tells you what kind of tool you actually have in your hand, and therefore what kind of reasoning it can support. A controlled vocabulary can’t answer relationship queries. A taxonomy can’t represent that two sibling categories share a property. Only when you get to ontology-grade structure — types, properties, relationships — can a machine (or a person) actually reason over the thing instead of merely browsing it.
That’s why, years later, I found myself pulling down a ready-made Wikipedia category graph and loading it into Neo4j — using the cats.csv and rels.csv datasets that map Wikipedia’s category hierarchy into a queryable graph database. It’s a small, almost throwaway technical note in my archive, but it’s the same impulse as the glossary: don’t just read the encyclopedia, turn it into a graph you can traverse, query, and reason over. A knowledge graph isn’t a fancier taxonomy. It’s a different kind of object entirely, and building one — even a toy one, out of Wikipedia categories — is the fastest way to feel the difference in your hands rather than just read about it.
How I Think About How I Work
If the glossary above is how I organize words, the next layer is how I organize work. Over the years I’ve collapsed my process down to a handful of named cycles, mostly because naming a process is the only way I’ve found to make it repeatable rather than accidental.
The core loop is Progressive Improvement & Learning Process (PILP) nested inside a Continuous Transformation Process (CTP) — the idea that improvement isn’t a single push toward a finish line but a repeating cycle where each pass through the work teaches you something that reshapes the next pass. Around any deliverable — a whitepaper, a specification, a presentation — I run an Initiate, Create, Review, Validate & Approve (ICRVA) Process, which I like to pronounce “I crave a” process, partly because a good process really is something you should crave, and partly because a mnemonic that makes you smile is a mnemonic you’ll actually use. The roles inside ICRVA map onto a standard RACI matrix of responsibilities — who’s Responsible, who’s Accountable, who’s Consulted, who’s Informed — nothing exotic, just discipline about who owns what at each stage.
But the piece I use most, especially when I sit down to write, is a purpose ladder for content: Awareness, Knowledge, Understanding, Expertise, Wisdom. Awareness is the overview — the “what’s out there” of a topic. Knowledge is the “what” of what’s being described. Understanding is the “how.” Expertise is deep, reliably demonstrated ability to perform and make sound judgments in the domain, built out of knowledge, skill, and experience. Wisdom is the broadest layer — judgment that applies experience, reflection, and values to decide what should be done, not merely what can be done. I keep a line from Proverbs pinned near this ladder, because it says the same thing better than I can: by wisdom a house is built, and by understanding it is established; by knowledge the rooms are filled with all precious and pleasant riches. Before I write anything longer than a paragraph, I try to know which rung I’m aiming for. A tutorial that promises “understanding” but only delivers “awareness” has failed its reader even if every sentence in it is true.
I keep a short list of other hierarchies I return to constantly, because naming the rungs of a ladder is often the whole trick: Dream, Desire, Want, Need. Sensing, Learning, Training, Experiencing. Keywords, Controlled Vocabulary, Glossary, Dictionary, Taxonomy, Ontology — the same ladder from the section above, restated as a personal habit rather than a formal definition. And for prioritizing product work, I’ve never needed more than three buckets: Need to have, Nice to have, and — my favorite, because it admits the truth about most feature requests — Neat to have. Most of what gets fought over in roadmap meetings is Neat dressed up as Need.
All of this is scaffolding for a simple belief: if you can’t articulate the process you’re running, you’re not really running a process, you’re improvising and calling it one. Naming the loop is what lets you improve it on purpose instead of by accident.
First Principles, Clique Speak, and the Tyranny of Consensus
I didn’t realize until relatively late in my career that I was, by temperament, a first-principles thinker. Once I understood the label, it became my go-to skill — the thing I reach for automatically when a problem is tangled. The idea, borrowed and re-stated by everyone from ancient philosophers to Elon Musk, is to break a complicated problem down into its most basic, defensible elements and then reassemble a solution from the ground up, rather than reasoning by analogy to whatever’s already been built. Reasoning by analogy is mentally cheaper — you do something because it resembles something else that was already done, or because it’s like what other people are doing. Reasoning from first principles costs more energy: you boil a problem down to what you’re as sure as possible is actually true, and then you build up from there. It’s slower. It’s also the only reliable way I know to get a genuinely non-linear result instead of a slightly-better copy of an existing one.
I’ll admit the honest corollary: I suspect most committed first-principles thinkers end up, whether they intend to or not, as monarchs of their own belief system. When you insist on rebuilding your understanding from bedrock instead of borrowing it pre-assembled, you stop outsourcing your conclusions to the room. That’s a feature when the room is wrong. It’s also, inevitably, a little lonely — and it puts you on a collision course with two things I’ve spent a lot of energy pushing back against: clique speak and consensus worship.
Clique speak is what happens when a group of insiders uses language — often perfectly polite, reasonable-sounding language — to limit a conversation to people already inside it, and to quietly close the door on newcomers or dissenters. I coined the term after years of watching it happen inside standards communities, where it’s endemic. It doesn’t announce itself as gatekeeping. It sounds like patience: “it’s not like we’re considering any of those topics for the first time.” “I know it will take time for you to trust that we’re trying to do the right thing for the community.” “There are things that have strong consensus, so we need to be careful not to reopen them.” Every one of those sentences is defensible in isolation. Strung together as a pattern, they do one job: they tell a newcomer that the conversation already happened, the conclusions are settled, and their job now is to catch up quietly rather than contribute. I collected ten real examples of this from a single community’s own survey report, not to shame anyone in particular, but because naming the pattern is the only way to inoculate a community against it. If you can’t recognize clique speak when it’s aimed at you, you’ll mistake it for wisdom.
And clique speak’s favorite weapon is the word “consensus,” which brings me to a position I hold pretty bluntly: consensus rarely creates truth or progress; it mostly creates more consensus. Consensus has its place — it stabilizes groups, and stabilization is sometimes exactly what’s needed. But it is structurally inclined to reproduce its own comfort rather than generate new understanding. At its best it harmonizes. At its worst it becomes self-referential, producing agreement about agreement and very little actual discovery. I’ll go further: consensus is often for those who can’t think for themselves.
I’m not the first person to notice this, and I like keeping company with the people who noticed it before me. Margaret Thatcher called consensus “the process of abandoning all beliefs, principles, values and policies in search of something in which no-one believes and to which no-one objects” — and, separately, called it “the absence of leadership.” Michael Crichton, writing about scientific consensus specifically, said that whenever you hear the consensus of scientists invoked as an argument, you should reach for your wallet, because in real science consensus is irrelevant — what counts is reproducible results. Abba Eban put it more cynically: consensus means everyone agrees to say collectively what no one believes individually. Søren Kierkegaard was blunter still: the crowd is untruth. Bertrand Russell pointed out that an opinion’s popularity is no evidence it isn’t utterly absurd, and Nietzsche observed that madness is rare in individuals but the rule in groups, parties, nations, and epochs — when a group agrees, it often just amplifies an unexamined error rather than correcting it. Mark Twain’s version is the one I repeat most: whenever you find yourself on the side of the majority, it’s time to pause and reflect.
None of this is an argument for contrarianism as a personality. It’s an argument for keeping first-principles thinking and clique-speak detection running at all times, especially in rooms that feel comfortable. My own advice to myself, which I’ve written down more than once, is to be a wanderer — to be daring, to go where no one has dared tread before, to think different and act different, deliberately and disruptively. Comfortable rooms rarely produce anything worth building.
The Art of Being Understood: Storytelling as a Bus Tour
Reasoning from first principles gets you to a correct answer. It doesn’t automatically get anyone else to believe the correct answer, and I’ve made peace with the fact that those are two entirely different skills. The second one — genuinely effective communication — comes down to a single image I keep returning to: start with something familiar to your audience, a belief they already hold, and then take them on a guided tour toward your eventual destination. Make sure everyone gets on the same bus before you pull away from the curb.
This is really just the Overton Window, applied deliberately as a rhetorical tool rather than observed as a political phenomenon. You don’t open a whitepaper at your own conclusion; you open it at the reader’s starting point, and you move the window one comprehensible stop at a time until they’ve arrived somewhere they wouldn’t have accepted if you’d simply announced it to them cold. It’s the same discipline, in miniature, that runs through this whole book’s account of change and technology adoption — nobody adopts a new idea by being handed the destination; they adopt it by being walked there.
Before I even start crafting the tour, I write an explicit Intended Audience Statement near the top of the document — something as plain as: the intended audience for this document is a broad range of professionals interested in furthering their understanding of Web 7.0 AgenticOS for use in software apps, agents, and services, including software architects, application developers, UX specialists, and people involved in standards efforts around decentralized identity, verifiable credentials, and secure storage. That sentence looks like boilerplate. It isn’t. Writing it down indispensably focuses the author’s mind — and the reader’s — before either of you commits to the tour.
Brands, Bricks, and Strategy Maps
Storytelling isn’t just how you write a whitepaper; it’s how a brand survives, and I’ve studied one particular case closely enough to build a whole presentation around it: Michael Eisner’s tenure as CEO of the Walt Disney Company — the rise and, eventually, the fall of a brand built and then slowly eroded under a single, dominant leader. The short version, distilled into the one slide I always tell people to look at if they don’t have time for the whole deck: a brand’s trajectory isn’t a straight line, and the same qualities that build it — a strong, centralizing, visionary hand — are frequently the exact qualities that later erode it, once the market, the culture, or the organization outgrows what that hand can still see clearly. It’s a cautionary case study I return to whenever I’m tempted to think a strong founder-CEO is an unqualified asset forever.
The structural version of the same lesson comes from two frameworks I like pairing against each other: Mitch Joel’s “Three Little Pigs” metaphor for business resilience, and Kaplan & Norton’s Balanced Scorecard strategy map. Joel’s framing is disarmingly simple: if the Big Bad Wolf of business is disruption, then your house of straw, your house of sticks, and your house of bricks each represent a different kind of response to it — and to survive, you can’t build only the straw or the sticks, you need the bricks.
Pig One is Transform — internal change, treated as an inside-out function. You rethink organizational structure, culture, and capability so you can meet customers where they actually are, not where your org chart assumes them to be. Pig Two is Innovate — building products, services, or experiences that actually connect with people, experimenting at the edges with new formats and technologies, designing for emotion and not just efficiency, and killing what doesn’t work early, because the wolf gets through a stick house that can’t evolve quickly. Pig Three is Transact — reworking how you actually enable commerce and conversion: the channels, payment flows, and customer journeys that let people say yes with as little friction as possible, closing the feedback loop so every transaction teaches you something that feeds back into transformation and innovation. Build only one of the three and disruption blows your house down. Build all three, in that order — foundation, frame, bricks — and you’re resilient.
What I find genuinely useful is mapping Joel’s three pigs onto the four perspectives of Kaplan & Norton’s Balanced Scorecard strategy map — Learning & Growth, Internal Process, Customer, and Financial — which describes a cause-and-effect flow from people and process excellence up through customer trust to financial growth. Transform (Pig One) is really an extension of the Learning & Growth foundation feeding the Internal Process perspective. Innovate (Pig Two) and Transact (Pig Three) live in the Customer and Financial perspectives further up the map. Neither framework improves much on its own; laid on top of each other, the folksy fairy tale gives the sober balanced-scorecard diagram some visceral urgency, and the scorecard gives the fairy tale some organizational rigor. That’s a pattern I keep noticing across all these thinking tools: the popular metaphor and the formal model are usually describing the same structure, and you understand both better once you’ve forced them to line up.
Digressions: Renaissance Art, the War of 1812, and the Butterfly Effect
Not everything in my archive is in service of a framework. Some of it is just the place my curiosity goes when I’m not writing specifications, and I’ve stopped apologizing for including it here, because these digressions turn out to rhyme with everything above more than I expect them to.
Renaissance art is one of those recurring interests. The Renaissance — roughly the fourteenth through seventeenth centuries in Europe — was a period when artists, architects, and writers set out to revive the classical values of ancient Greece and Rome, and the result was a genuine revolution in both style and subject matter. The most notable feature of Renaissance art is its realism: Leonardo da Vinci, Michelangelo, and Raphael all pursued lifelike depictions of the human form and the natural world, visible in works like Leonardo’s The Last Supper, Michelangelo’s David, and Raphael’s The School of Athens. Subject matter shifted too — away from an almost exclusive focus on religious themes and toward landscapes, portraits, and historical events, reflecting a growing interest in the secular world and in classical learning. The same revival reshaped architecture: Filippo Brunelleschi and Leon Battista Alberti brought classical Greek and Roman forms back into buildings like the Medici Palace in Florence and St. Peter’s Basilica in Rome. I don’t think it’s an accident that I keep returning to this period. It’s the last time in Western history that a civilization deliberately reached backward to first principles — the “classical values” of an earlier era — and reasoned forward from them into something genuinely new, rather than just iterating on whatever the immediately preceding generation had done. That’s the same move I described above as first-principles thinking, just performed by a civilization instead of an individual.
The War of 1812 is a different kind of digression, but it lands on a theme that connects directly back to my argument about consensus. It was fought from 1812 to 1815, primarily between the United States and Great Britain, with the fighting concentrated in North America and at sea — and it had no single cause. British impressment of American sailors and trade restrictions tied to the Napoleonic Wars combined with American grievances over national honor, westward expansion, and a Congress full of War Hawks like Henry Clay who believed Canada could be easily conquered. Indigenous nations, led in part by Tecumseh, allied with Britain against American expansion, seeing the British as the lesser threat. American invasions of Canada failed at Queenston Heights in 1812; Tecumseh was killed at the Battle of the Thames in 1813; the British burned Washington in 1814; Baltimore held and inspired “The Star-Spangled Banner”; and Andrew Jackson won the Battle of New Orleans in 1815 — after the peace treaty had already been signed, because news traveled too slowly to stop the fighting. The Treaty of Ghent restored the pre-war borders and settled almost nothing about the underlying issues, which simply faded once Napoleon was defeated in Europe.
What makes the war worth including in a chapter about thinking tools isn’t the battle sequence — it’s how differently each side remembers the exact same set of events. Americans remember it as a successful second war of independence. Canadians remember it as a defensive war that preserved their country from annexation and gave them figures like Laura Secord and Isaac Brock. The British barely remember it at all — a minor sideshow next to Napoleon. And for Indigenous nations, it was a tragic turning point: Britain abandoned its support after the war, and American expansion into their lands only accelerated. Four groups, one war, four durable and mutually incompatible consensus narratives, none of which is simply “the truth” and all of which are sincerely held. It’s the clearest illustration I know of my point about consensus a few sections back: agreement within a group tells you what that group has settled on believing, not what actually happened. History doesn’t resolve that tension — it just lets every side keep its own consensus intact.
The butterfly effect closes the loop between all of this and epistemic humility, which is really the quality underlying every tool in this chapter. It comes from chaos theory, specifically Edward Lorenz’s work in the 1960s, and it describes sensitive dependence on initial conditions in non-linear dynamical systems: two starting states that differ by an infinitesimally small amount can evolve into dramatically different trajectories, making long-term prediction effectively impossible even though the underlying system is fully deterministic — no randomness required. Lorenz discovered this almost by accident, when rounding a weather model’s input from 0.506127 to 0.506 caused the simulated weather to diverge completely over time. The popular phrasing — a butterfly flapping its wings in Brazil setting off a tornado in Texas — is a metaphor, not a mechanism; it is not a claim about physical causation. It’s worth being precise about what the butterfly effect does not say, because the misreadings are everywhere: it doesn’t say small actions always have huge consequences, it doesn’t say everything is connected to everything else, and it certainly doesn’t say the butterfly causes the tornado. It applies to weather, turbulent fluids, some ecological systems, and certain economic or market models — not to linear systems, not to systems with strong damping or error correction, and not to moral or social claims dressed up rhetorically as chaos theory without any actual evidence behind them.
The deeper implication, and the one most people skip past, is that the butterfly effect describes a limit to knowledge, not just a limit to control. Even with perfect equations and infinite computing power, you’d still need infinitely precise measurements to predict a chaotic system’s long-term behavior — and infinitely precise measurement is physically impossible. The lesson is epistemic humility, not mysticism.
Closing
Line these tools up and a shape emerges that I didn’t fully see until I put them side by side for this chapter. Define your terms precisely, because a controlled vocabulary and an ontology are not the same kind of object and confusing them will cost you later. Name your process, because an unnamed process can’t be improved on purpose. Reason from first principles instead of by analogy, because analogy only ever gets you a slightly-better copy of what already exists. Listen for clique speak, because it’s the sound insiders make while quietly closing a door. Distrust consensus as evidence of truth, because a room agreeing with itself is not the same thing as a room being right — the War of 1812 alone proves that four different groups can each hold a rock-solid consensus about the same events and still all be describing different wars. Build your case the way you’d plan a bus tour, starting from what your audience already believes. Build your organization on all three of Transform, Innovate, and Transact, because a house of straw or sticks alone won’t survive the wolf. And underneath all of it, keep a working sense of the butterfly effect’s real lesson: even with the best tools in this chapter applied perfectly, there is a hard limit to what you can know and predict, and the honest response to that limit is humility, not paralysis. That, more than any single post here, is the thinking tool I use the most.
Chapter 3: A Life in Technology: Michael Herman
Most of this book is about ideas — about graphs and protocols, about who owns a piece of AI-generated text, about whether a decentralized identifier can be trusted the way a handshake once was. Before going further into that territory, it’s worth pausing to say something about the person doing the thinking. I’ve spent more than five decades building software at the edges of whatever transition technology happened to be going through at the time, and I’ve spent all of that time as a son, a father, a neighbor, and, for the last stretch of my life, a resident of a small corner of southeastern Alberta most people will never have reason to visit. Both halves belong in this book. The systems I design are abstract by necessity, but the reasons I care about getting them right are not abstract at all.
Fifty Years at the Frontier
I trace my formal training back to the University of Waterloo, where I earned a Bachelor’s and a Master of Mathematics in Computer Science, specializing in computer graphics, and where I served as the founding lab manager of the Computer Graphics Laboratory. That early grounding in graphics and mathematics turned out to shape nearly everything that came after, even when the work had nothing obviously to do with pixels or polygons.
From Waterloo, my career carried me through a sequence of companies that, looking back, each caught a different wave of the same long story: computing moving from centralized machines toward client-server systems, and then from client-server systems toward networked and distributed ones. I held senior product development roles at Optical Recording Corporation, Alias/Wavefront, and Star Data Systems, where I helped build Windows-based platforms for enterprise document management, advanced graphics, and financial systems. One of those projects, Alias Upfront for Windows, was singled out by Bill Gates in a 1991 Windows World keynote as the most innovative new graphics product for Microsoft Windows — a nice marker, in hindsight, of how early I was already working at the boundary of what the platform of the moment could do.
I later spent years at IBM and then at Microsoft, where my work took two distinct but related forms. On one side, I served as a lead enterprise consultant on complex infrastructure engagements for major financial institutions, utilities, and public-sector organizations — the unglamorous, high-stakes work of making very large organizations’ technology actually function. On the other side, I worked inside the Microsoft Exchange and SharePoint Portal Server product groups, leading developer technical readiness programs for internal field teams and partners around the world, translating new platforms into something thousands of other engineers could actually build on. Across all of it, the common thread was helping large institutions move from one architectural era into the next without losing what worked in the one before.
In more recent years, that same instinct has pulled me toward the architectural foundations of digital trust and decentralized identity. I’m a named contributor to the W3C Decentralized Identifier (DID) specification, and I’ve contributed to initiatives within the Decentralized Identity Foundation and Trust over IP. Through the Web 7.0 Foundation and the Trusted Digital Web, the bulk of my current work is first-principles thinking about agentic systems, verifiable identity, and trust-native internet infrastructure — examining how autonomy, accountability, and cryptographic assurance need to be built into the protocol layer of whatever comes after today’s internet, rather than bolted on afterward. It is, in a real sense, the same question I’ve been asking since Waterloo: how do you take something enormous and unruly and give it a structure people can actually trust and build on.
The Invention of Graphitization
Somewhere in the middle of that arc, working as a blockchain developer, enterprise architect, and data scientist at Parallelspace Corporation, I coined a term for the pattern I kept noticing everywhere I looked: #Graphitization. I described it at the time as a closed-loop feedback process for ingesting, modeling, analyzing, visualizing, and managing the life cycle of any strategy, system, asset, architecture, or process — the idea being that almost anything, if you looked at it correctly, was really a graph: a network of connected objects and relationships, each one carrying its own metadata, waiting to be surfaced and optimized.
What struck people who followed the work was how far I was willing to push that idea. I applied #Graphitization to the obvious targets — enterprise architecture using ArchiMate, cloud services platforms, IoT systems, enterprise data and master-data structures — but also to things nobody expected a graph model to touch: aircraft engines, muscle cars, and other high-performance engine systems, on the theory that improving the design of a jet turbine and improving the design of a global cloud platform were, underneath the surface details, exercises in the same discipline. I graphitized organizational principles and belief systems too, running Ray Dalio’s Bridgewater principles and Jeff Bezos’s Amazon Leadership Principles through the same process, treating a company’s stated values as just another system worth modeling and understanding.
That period also put me deep into blockchain development. I was the principal author of NEP-10, the NEO Enhancement Proposal for Composite Smart Contracts, and I built SerentityData Graph, an open-source entity-relationship modeling and code-generation tool that let a single data model drive both on-chain smart contract data and off-chain application data, with full Neo4j integration for visualizing and analyzing all of it together. A related project, NeoDraw, took fourth place and a $15,000 prize in the NEO-Microsoft dApp competition. None of that work was really about blockchain for its own sake — it was about proving that the graph-based approach could hold up under the added discipline that a distributed ledger demands.
Looking back at that stretch of my career now, from the vantage point of Web 7.0 and decentralized identity, I can see it clearly as a rehearsal for everything I do now. The conviction underneath #Graphitization — that trust, structure, and meaning live in the relationships between things, not just the things themselves — is the same conviction underneath a decentralized identifier or a verifiable credential. I just didn’t have the vocabulary yet for what I was building toward.
Bindloss, Jenner, and Patricia: A Life Rooted in Alberta Land
For all the years spent moving through Seattle, Toronto, and the placeless geography of global enterprise software, my actual home has been a fixed point: Bindloss, Alberta, a hamlet in the southeastern corner of the province, not far from the hamlets of Jenner and Patricia and the stretch of prairie and badland coulees that runs along the Red Deer River. It’s not a place most of the people I work with in decentralized identity or enterprise architecture will ever pass through, and that contrast has always felt meaningful to me rather than incidental.
In June of 2024, I put together a short video of Patricia and Jenner — a quiet, unglamorous record of the land, the roads, the grain elevators and open sky of that part of Alberta. It isn’t the kind of thing that needs much explanation. It’s the same impulse that sends anyone back, camera in hand, to the places that made them: not to argue a point, but simply to look again at what’s there and make sure it’s remembered. After a career spent building abstract models of enormous, distributed systems, there is something grounding about pointing a camera at an actual place and letting it just be what it is.
Wishes for a New Albertan
In February of 2021, I wrote a set of wishes for a new Albertan — a poem, really, meant to be read slowly, the way the broadcaster Paul Harvey used to deliver his own reflections. I republished it in the fall of 2025, and it has stayed one of the pieces of writing I’m proudest of, precisely because it has nothing to do with technology at all.
The wishes are small and specific in the way that real advice usually is: ask your dad for a fingertip drip of Jameson, learn to kiss passionately, wear Bleu de Chanel, smile a lot. Learn the polka, the two-step, and the jive, and trust that slow dancing will come on its own. Buy flowers, lots of flowers. Take your mom out on school nights. Throw the baseball with your dad. Learn to use a real calf rope, drive a pickup truck and nothing else, learn to pick crocuses and wild roses, and know that Valpolicella Ripasso is a fine wine until you can afford Amarone. Travel — to Spain, the Netherlands, and Poland. Eat great food. Make your mom buy you a pickle canner. Love your mom and your dad, but especially your mother. Never forget you’re an Albertan. Buy a ranch some day. Wherever life takes you, never forget what an Alberta sky looks like. Love country music. And smile — the poem returns to that word again and again, more insistently each time, until by the end it isn’t really advice anymore so much as a blessing.
I don’t think it’s a coincidence that the same person who spent a career trying to model the underlying structure of enterprises, cloud platforms, and now the trust architecture of the internet also sat down and wrote, with total sincerity, that a new Albertan should learn to pick wild roses and never forget what the sky looks like at home. Both are attempts to pass on something true and durable to the people who come after.
In Memory of Dennis Swenson
At the end of December 2025, I posted a short, wordless memorial for Dennis Swenson: three photographs, nothing more. I’ve thought about whether to say more here than the original post did, and I’ve decided the restraint was the right choice the first time and deserves to be honored rather than filled in after the fact. Some losses don’t need captions. In a small community like the one around Bindloss, a life well lived among neighbors is its own statement, and sometimes the most respectful tribute is simply to hold up the pictures and let people who knew him sit with them for a moment. I share the memory of Dennis Swenson here in that same spirit — as a quiet acknowledgment that the work in the rest of this book, however far it reaches into questions of digital trust and decentralized systems, is still the work of someone who belongs to a real, physical community, and who has said goodbye to people in it.
A Life at Both Ends of the Wire
Put together, these five pieces are a strange but honest self-portrait. There’s the resume — Waterloo, Alias/Wavefront, IBM, Microsoft, the W3C DID specification, the Web 7.0 Foundation — the record of someone who has spent his professional life trying to find the graph hidden inside every enormous system he’s ever been handed, from a jet engine to a global cloud platform to the trust layer of the internet itself. And there’s everything else: a video of two Alberta hamlets, a poem about pickup trucks and wild roses and Alberta skies, three photographs standing in for a eulogy. I don’t experience these as separate lives. The same person who wants a decentralized identifier to be something a human being can actually trust is the person who wants a new Albertan to remember what the sky looks like at home, and who wants a friend’s memory handled with more care than words. Whatever theories and architectures fill the rest of this book, they come from somewhere — and that somewhere is Bindloss, Alberta, and the fifty years of work and family and land that brought me here.
Chapter 4: Inside Microsoft: History, Stories, and Lessons
I have spent the better part of forty years standing in one relationship or another to Microsoft: as a young developer squinting at pre-release SDK documentation that fit in three beige binders, as an internal Microsoft Consulting Services consultant training the field, as the founder of an ISV that bet its business on a Microsoft collaboration platform, and — more recently — as an outsider who left the mothership in 2001 and has spent the twenty-five years since watching the company from a considerable and useful distance. That range of vantage points is, I think, the only real qualification I have for writing about Microsoft at all. I was never important enough to shape the company’s strategy. But I was present enough, often enough, in enough different rooms, to watch the same pattern repeat itself for decades: brilliant technology, built by brilliant people, released into the world through a strategy apparatus that could never quite agree with itself about what it was building or why. This chapter is my attempt to tell that story through the pieces of it I actually witnessed — the code, the products, the arguments, and the running jokes — rather than through the received wisdom that gets rehearsed every time somebody writes a Microsoft retrospective.
Learning Windows From the Inside Out
My Microsoft story starts a long way from Redmond, in a research shop in Toronto called Optical Recording Corporation, in the spring of 1986. We were trying to build an optical-disc-based document storage and management system — don’t laugh, for 1986 that was genuinely ambitious — on top of the very earliest versions of Windows you could get your hands on: Windows SDK version 0.989, Windows 1.01, Windows 1.02. This was Windows before Windows was a business strategy. It was a fragile, ambitious little windowing layer sitting on top of MS-DOS, and it came with a runtime, an SDK, maybe a copy of the Microsoft C compiler, and a documentation library you could carry under one arm.
If you want to know what “generic” software looked like in that world, look no further than generic.c, the sample application Microsoft shipped with the Windows 1.0 SDK. It is, structurally, everything Windows programming was for the next fifteen years, distilled to its essence: a WinMain that registers a window class and pumps a message loop, a MainWndProc that switches on WM_PAINT, WM_COMMAND, and WM_DESTROY, and an AboutDlgProc that exists mostly so the sample has somewhere to put a copyright notice. The whole thing paints “Hello, Windows!” at coordinates (10,10) and calls it a day. I keep a copy of it around — I even resurrected it recently, dressed up with a nod to the AgenticOS work I’m doing now — because it’s a useful reminder of how small the surface area of a “platform” used to be. One header file. A couple of dozen well-understood messages. No ambiguity about what you were building or what API you were building it on. That clarity did not survive contact with Microsoft’s growth.
I attended my first Microsoft Windows developer event in the fall of 1987, in a modest hotel meeting room in Santa Clara — five or six rows of chairs, fewer than a hundred people in the room, Steve Ballmer running the show as MC, and a technical lead named John Butler (memorable mostly for his ponytail, and later a key figure in building what became Microsoft University) doing the deep-dive. The giveaway was a white cotton book bag with a pale blue Windows logo on it, containing the runtime, the SDK, and that entire three-binder documentation set. It is almost impossible, from where the company sits today, to convey how small and how personal that world was.
It got a little less small a few years later, when I was part of the small team at Alias Research — myself, James Boritz, Ming Mah, Richard Brath, Dan Whitely, and Jon Steinberg, working out of a back room on the third floor — that built Alias Upfront for Windows, a low-cost 3D package for architects, using the Spacemaker technology Alias had acquired. Upfront became Alias Research’s first desktop software product, and it earned a line from Bill Gates himself at a major Microsoft conference: “In the graphics area, I picked Upfront from Alias Research. It is really an incredible tool for making sure the design is exactly right.” I have no idea to this day whether Upfront made $2 million or $200,000 — the number moves depending on who’s telling the story — but the point was never the revenue. The point was that in those years, a small team could build something genuinely novel on Windows and get noticed by the top of the company for the quality of the work, not the size of the deal.
That kind of direct visibility into Microsoft’s leadership became a recurring theme for me. In the fall of 1997 I was honored to present to Bill Gates, Nathan Myhrvold, and about thirty development managers at the Billg Fall 1997 Retreat on Improving the Software Development Processes at Microsoft. My topic was Orthogonal Defect Classification — a rigorous way of categorizing software defects so you can actually learn something systemic from your bug database instead of just closing tickets. I mention it not because the talk itself was historic, but because it captures something about that era of Microsoft that later got lost: an internal culture that was still curious enough, and still small enough in the ways that mattered, to put an outside consultant in a room with its CEO and its Chief Technology Officer to talk about defect taxonomies.
That same year gave me one of my favorite Microsoft stories, and one that says more about the company’s character than any strategy document could. Around May of 1997, one of the largest banks in Canada — a major Microsoft customer headquartered in Toronto — had committed to running server-side Java before server-side Java, J2EE, or anything resembling that ecosystem really existed. They were running it on the IE4 Java VM, at a time when Microsoft was proud simply to keep that VM running “dancing elephants” inside the browser for twenty-four hours without crashing. Nobody at Microsoft had imagined the IE4 VM hosting what was, at the time, the largest server-side Java application in the world. It crashed constantly. The bank blamed our VM, correctly, since it was the only VM — not IBM’s, not Sun’s — that would even attempt to run the thing.
I ended up in a standoff with Charles Fitzgerald, whose job, on behalf of Brad Silverberg, was to protect the IE4 ship date from exactly this kind of distraction. Bill Gates was already leaning on Brad and Charles not to get pulled into it. Then Steve Ballmer came to Toronto, got thoroughly reamed out by an ex-IBM bank vice president, and instantly became my strongest ally. Months later, at Microsoft’s internal worldwide sales conference in Orlando, Ballmer physically inserted himself between me and Bill Gates to make sure the story got told — fingers jabbing the air, insisting Bill listen and learn what it meant to take an enterprise customer’s pain seriously. That night I ended up in Ballmer’s hotel suite, just the two of us and a conference call with Paul Maritz and the Java VM team, working through whether the bank’s usage was on-strategy or off-strategy, and — once Paul said it wasn’t off-strategy — simply demanding a yes-or-no decision on fixing the bug. We got the yes. The multi-threading synchronization bug was fixed within the week, in time for Paul’s call with the bank’s VP. Afterward, Ballmer would high-five me in the hallway of the Canadian subsidiary, which used to genuinely confuse people who didn’t know the backstory. That is the Microsoft I remember from the inside: capable of moving with real speed and real conviction, once you got the right two or three people in a room and forced a decision.
Groove, SharePoint, and the Business of Collaboration
By the early 2000s I had left Microsoft proper and founded Parallelspace Corporation, and the center of gravity of my work shifted to collaboration software — first around Ray Ozzie’s Groove Workspace, and then around SharePoint.
Parallelspace built what we called “Truly Collaborative Business Solutions” for Groove Workspace: custom Groove Tools created with my colleague Sanjay Malhotra, including Parallelspace eMail, a fully integrated version of Outlook that ran transparently inside Groove. We built the Groove Tool development environment itself out of the C preprocessor bolted onto Microsoft Visual InterDev — a now-deprecated web development tool that was itself a precursor to Visual Studio. It was scrappy, first-principles engineering in the truest sense: nobody had built us a proper toolchain for extending Groove, so we built our own out of whatever was lying around. Ray Ozzie’s public reflections years later, at the Computer History Museum, on the importance of understanding yourself as a builder resonated with me for exactly this reason — Groove tooling was where I first really understood myself as what I’d now call a first-principles thinker, someone who would rather assemble a working solution out of mismatched parts than wait for the “right” platform to arrive.
SharePoint became the bigger and longer chapter. Twenty-five years ago, Microsoft shipped Release Candidate 1 of SharePoint Portal Server 2001 — internally codenamed “Tahoe.” Tahoe’s first release ran on top of the Exchange Server 2000 Web Storage System, but that dependency didn’t last. Co-released alongside it was Windows SharePoint Services (WSS), a free component of Windows Server 2000 that stored documents and metadata in SQL Server instead. By the time SharePoint Server 2003 shipped, WSS had effectively become SharePoint’s “kernel,” and the Web Storage System dependency was gone. That migration — from a proprietary Exchange store to a SQL-Server-backed WSS foundation — is a small case study in how quickly Microsoft could change its own storage strategy mid-flight, something that becomes relevant later in this chapter.
I worked that transition from the inside, as an internal Microsoft Consulting Services EC3 consultant responsible for developer, partner, and field readiness on the SharePoint product group. I was speaker manager, content manager, and a speaker at the very first SharePoint Field Technical Readiness Conference — a week-long event in January 2001 where we trained the first cohort of roughly seven hundred MCS and partner consultants on SharePoint Portal Server install, configuration, and operations, on Web Parts, on Web Storage System architecture and development, on Search, and on Windows SharePoint Services. I spent about a quarter of my working life devoted to SharePoint in those years. It helped me buy my first ranch. SharePoint went on to become the fastest-growing product in Microsoft’s history and the fastest Microsoft product to reach a billion dollars in cumulative revenue — a product, as one of its leaders liked to put it, that had competing products but no competitive products. Over the following decade I wrote a long shelf of whitepapers and evaluation guides for the SharePoint product group and Microsoft IT Showcase — on document library migration, on deploying SharePoint as Microsoft’s own enterprise intranet portal, on Shared Services architecture, on advanced migration scenarios, on performance management — climbing from twenty-page product-help documents up through a 126-page evaluation guide for SharePoint 2007. Those documents chart, page by page, an unusually long and successful product life. But they also chart something else: a company that kept quietly rebuilding its own storage foundations underneath a product line it was simultaneously trying to sell as stable and strategic. Outlook 10 (what became Office XP) quietly dropped support for the local Web Storage System around the same period, for reasons that turn out to be central to the rest of this chapter.
A Brief History of Disconnected Strategies
If there is one thread that runs through my entire relationship with Microsoft — one I kept independently rediscovering across different products, different decades, and different job titles — it’s this: Microsoft has never had much trouble inventing brilliant technology. It has had chronic, structural trouble deciding, and then communicating, which technology was actually strategic.
The clearest single incident happened on December 17, 2000: the cancellation of the Local Web Storage System (LWSS) project, which killed its planned inclusion in “Outlook 10” (Office XP). I remember the date precisely because the very next day I was asked to present at the Microsoft Collaboration Partner Advisory Council meeting at the Atlantis Hotel in Nassau — a lovely setting for what turned into a two-day beating. Roughly every forty-five minutes, Robert Ginsberg, co-founder of one of the world’s leading Exchange Server WSS development shops, would shake his head and shout, “How could you, Microsoft, do this to us?” He was right to be furious. He and his business partner, Andy Sakalian, had invested enormous time mastering LWSS internals and building tooling for prospective LWSS ISVs — tooling for a platform that Microsoft had just quietly euthanized. Schitt happens everywhere, but it was always more entertaining when it happened at Microsoft; the trip did end on an upbeat note, when Andy introduced me to a jeweler from Montreal who taught me how to play blackjack “the real way,” and I walked away from the Atlantis casino tables at four in the morning about $900 richer.
The LWSS cancellation wasn’t an isolated misstep; it was one data point in an ongoing, very public argument about Microsoft’s storage strategy that played out at every Professional Developers Conference I attended after leaving the company. At PDC 2001, I developed a running, unspoken competition with journalist Mary-Jo Foley over who could get to the microphone first during Bill Gates’s executive Q&A to ask the same question: when was Exchange Server actually going to ship on a SQL-Server-based unified storage system? Bill always had a good answer. I don’t think either of us ever really believed the answer, which was rather the point — the question kept needing to be asked because the strategy kept not resolving.
It didn’t resolve in the “Longhorn” era either, even though Longhorn’s most ambitious piece — WinFS, the SQL-relational-database-based Windows File System — was explicitly Microsoft’s attempt to finally deliver that unified storage vision at the operating-system level. I was involved with Project Longhorn between roughly 2001 and 2002, from design preview and feedback through consulting and PM technical training — including training built around the Groove Workspace system architecture I already knew intimately from the Parallelspace years. Longhorn’s storage ambitions traced directly back to Bill Gates’s March 2001 “HailStorm” announcement of user-centric, consistent, personalized experiences across Microsoft’s platform, and WinFS carried that torch for years afterward — surfacing as a surprise early beta announced in InfoWorld in September 2005, years after the original Longhorn timeline had assumed it would already have shipped as part of Windows. WinFS eventually died without ever shipping as part of Windows. It is, to this day, one of the most talented engineering efforts Microsoft ever cancelled, and it’s a direct descendant of the same unified-storage question I kept lobbing at Bill Gates from PDC microphones.
Nowhere was the pattern more explicit than at Microsoft’s own Office Developers Conference in February 2005. I asked, on the record, a question that I think stands as a fair summary of my entire critique of the company: “It’s nice to see Microsoft consolidating around a smaller set of core technologies, but when it comes to electronic forms, Word and Excel have their own point solution, Outlook has its own point solution, InfoPath has its own point solution, Access has its own point solution. In the developer platform you have ASP.NET and WinForms. We’re constantly in a situation where we’re trying to guess which ones are strategic. Can you give us some insight?” Bill Gates and Steven Sinofsky answered, as they always did, thoughtfully and at length — and the honest truth underneath their answer was that nobody, including them, had a clean way to reconcile four separately-built forms technologies inside one product suite. Another attendee at that same conference, Mark Moore, formerly of KPMG and an early SharePoint Portal Server 2001 adopter, put the deeper problem even more sharply: Microsoft’s customers had been on a “collaboration path” running from Outlook and Exchange, through the old Digital Dashboard, through SharePoint 2001 and SharePoint 2003, with almost nothing carried forward from one milestone to the next. He asked, more in hope than expectation, whether “this cycle of creative destruction” was finally coming to an end.
That same year, ahead of PDC 2005, I was publicly wondering in print whether the conference’s own session structure would repeat the pattern at the developer-platform level — I specifically flagged that the session “Choosing the Right Presentation Technology: Avalon, Windows Forms, ASP.NET, IE, and More” made no mention of InfoPath “12” or the forms server Microsoft had already demonstrated at TechEd that year, and I encouraged attendees to rate the session poorly if it didn’t address the gap. My question at the time was blunt: was PDC going to present an integrated view of the Microsoft platform, or was it going to be “one large Microsoft technology fair,” with each product group given a booth to promote its own bits and developers left to guess what was actually strategic? I put the odds at fifty-fifty. Jon Udell, covering the same conference, made the sharper observation underneath mine: PDC itself was structurally ahistorical. It was built to showcase futures, not to account for follow-through, which is exactly why attendees spent the hallways “reading the entrails,” trying to divine which of the parade of names — Windows, NT, Win95, the Internet, Tablet PC, .NET, HailStorm, WinFX — would still matter in eighteen months.
That pattern predates 2005, too. Back around 2000, when .NET was still being spelled three different ways by three different product groups inside the same building, Microsoft had to stand up an internal “.NET police force” — led, appropriately, by my old Java Jam sparring partner Charles Fitzgerald — whose entire job was to swoop in on presenters and authors and force them to standardize the spelling of a three-letter word that didn’t actually mean anything yet. I was in the middle of that chaos too, having moved into MCS Canada’s EC3 team (the Enterprise Connectivity Competency Center, formed out of the acquisition of a Toronto ISV called Linkage) and been handed the assignment of writing the Exchange Server “.NET strategy” whitepaper for Thomas Rizzo — a strategy I had to interview a dozen people to reconstruct and, frankly, partly invent, since it didn’t fully exist yet. Around that same period Microsoft was also trying to figure out, in full public view, how a smaller set of “core” storage technologies would underpin the whole developer platform — the trade press covered it as Microsoft “aiming to shake up the storage world,” which is a generous way of describing an internal argument that hadn’t yet been settled when the press release went out.
It became such a recognizable pattern that Microsoft people had a phrase for it, borrowed from television. “Is it a floor wax or a dessert topping?” comes straight out of a 1976 Saturday Night Live parody commercial — the “Shimmer” sketch, with Dan Aykroyd and Gilda Radner arguing over what their new product actually was, and Chevy Chase, as the pitchman, resolving the fight by declaring it was both, spraying it onto a mop and a dessert to prove it. Inside Microsoft, when a partner or a product group pitched something that seemed to be trying to be too many unrelated things at once, we’d ask each other, half-joking, whether it was a floor wax or a dessert topping. It was shorthand for fuzzy product definition and scope creep, and it applied constantly — to the eforms sprawl across Word, Excel, Outlook, InfoPath, and Access; to the storage strategy that moved from Exchange’s Web Storage System, to WSS-on-SQL-Server, to WinFS, to whatever came after WinFS died; to a developer platform that offered you ASP.NET, WinForms, and Avalon in the same year with no clear map of which one you were supposed to build your career on. The joke worked because everyone inside the building recognized the disease immediately. What was harder, in my experience, was getting anyone with the authority to fix it to admit the disease was systemic rather than incidental.
Whither Microsoft: An Outsider’s View, Decades Later
I’ve been asking some version of the “which one is strategic?” question in public for a quarter of a century now, so it caught my attention when, this spring, an outside operations consultant named Feroze Motafram — someone with no software background at all, a Seattle-area neighbor of Microsoft rather than an alumnus of it — published an outsider’s assessment of the company that landed on almost exactly the same diagnosis, from a completely different angle and thirty years of distance.
Motafram’s starting observation was financial: Microsoft down roughly 25% in the first quarter of 2026, its worst quarter since the 2008 financial crisis, despite genuinely strong underlying numbers — revenue up 17% year over year, operating margins above 47%, quarterly cloud revenue past $50 billion for the first time. His question was the right one: what does the market understand about this organization that the headline numbers don’t capture? His answer, distilled, was that decades of monopoly-grade lock-in on Office had let Microsoft substitute “what can we get away with?” for “what does the customer need?” — that processes and committees multiply when your revenue arrives regardless of whether the product is great or merely good enough, and that this kind of institutional complacency leaves a mark that doesn’t disappear just because the competitive landscape changes underneath it.
He credited Satya Nadella fully and fairly for the Azure pivot and for genuinely arresting the cultural damage of the stack-ranking years — and then noted, from conversations with current employees, that the performance-review system which replaced stack ranking hasn’t obviously changed the underlying instincts, only the vocabulary. His most concrete piece of evidence was Copilot: fifteen million paid subscribers converted out of a captive base of four hundred and fifty million Microsoft 365 users, a 3.3% conversion rate for what Microsoft has positioned as its single most strategically important product. He layered on the human dimension too — the degree to which conversations among Microsoft employees in the Seattle corridor gravitate toward org charts and reorgs rather than toward what’s being built, and the genuine, well-founded anxiety among the large H-1B-visa-holding share of Microsoft’s engineering talent, anxiety that predictably produces risk-averse, execute-what-already-exists behavior rather than the bold bets a company in Microsoft’s competitive position actually needs. And he flagged the structural risk sitting underneath all of it: $281 billion of Microsoft’s $625 billion revenue backlog tied to a single counterparty, OpenAI, an unprofitable startup that had just signed a landmark hosting deal with Amazon Web Services — directly undercutting the Azure exclusivity Microsoft had treated as a strategic cornerstone — while Microsoft simultaneously builds its own MAI-1 model as a hedge against the very dependency it created. A hedge stacked on top of a bet, as he put it, dressed up as prudence.
I don’t have anything to add to Motafram’s numbers, and I don’t need to. What struck me, reading it, was how familiar the shape of the argument was. Swap “Copilot conversion rate” for “eforms point solutions,” swap “OpenAI dependency” for “Web Storage System dependency,” swap “MAI-1 as a hedge” for “WinFS as the unified-storage answer that never shipped,” and you are reading the same institutional pathology I was describing from inside PDC sessions and Office conferences twenty years earlier. The names change. The org chart changes. The technology stack changes completely, generation after generation. What doesn’t change is a company whose engineering talent is, and always has been, extraordinary, sitting inside a strategic apparatus that has never quite been able to tell its own developers, partners, and — now — its own market which of its many simultaneous bets is actually the strategic one.
Coda
None of this is an argument that Microsoft is a failure. It manifestly isn’t — SharePoint alone paid for a ranch, and the ranch is still mine. The company has employed and enriched an extraordinary number of extraordinarily talented people, myself included, and it has shipped technology, from Windows itself down to WinFS’s unrealized ambitions, that changed how the industry thought about what a platform could be. But I keep coming back to generic.c — that tiny, unambiguous sample application from 1985, one header file and three message handlers, doing exactly one clear thing — as a kind of control group for everything that came after it. Somewhere between that simplicity and today’s stack of Copilot, Azure, OpenAI dependencies, and MAI-1 hedges, Microsoft scaled its ambition much faster than it scaled its ability to tell a coherent story about which ambition mattered most. I watched that gap open in 2000, in 2001, in 2005, and in every PDC in between; an outsider watching from a Seattle backyard in 2026 is describing the same gap, just with a different set of nouns. That continuity, more than any single product or any single quarter’s stock price, is the real lesson of my history with Microsoft — and it’s a large part of why, when I think today about how technology platforms should be built and governed, I keep reaching for architectures where “which one is strategic” isn’t a question a company gets to leave permanently, profitably unanswered.
Chapter 5: Decentralization and the Economics of Platforms
Everyone talks about decentralization as if it were a technology choice — a stack you adopt, a protocol you swap in for a database. It isn’t. Decentralization is an economic argument first and a technical architecture second. Before I ever get to DIDs, DIDComm agents, or verifiable credentials in the chapters that follow, I want to lay out why I think the economics point in one direction, and only one direction, over the long run. That means being precise about what decentralization and centralization actually mean, working through a real case — the mobile app ecosystem, which is the best-documented platform fight of the last fifteen years — and then following the money, literally, down to the question of what currency is for and why data behaves like steam. By the end of this chapter I want it to be obvious that the shift from client/server to cloud to decentralization is not a stylistic preference. It’s the next entry in a sequence of computing paradigm shifts, each one driven by economics that eventually overwhelmed whatever incumbents had built on the paradigm before it.
Definitions: What We Actually Mean by Decentralization
I get asked constantly what I mean by “decentralization,” usually by people who assume it’s a synonym for “no company is in charge” or “blockchain.” Neither is right, so let me define the terms the way I actually use them.
Decentralization is the shift from centralized control of identity, data, compute, and decision-making toward a distributed ecosystem where trust emerges from cryptographic proofs, verifiable credentials, and autonomous agents — not institutions. Instead of relying on a single platform or cloud to authenticate users, store data, run applications, or mediate transactions, decentralization enables individuals, organizations, and intelligent agents to interact through open protocols, self-sovereign identities, shared governance, and value-aligned automation. The result, when it works, is a more resilient, equitable, and interoperable digital environment: trust is built into the architecture itself rather than into a brand or a terms-of-service agreement, users retain control over their digital existence, and intelligent agents operate collaboratively instead of being owned or constrained by a proprietary platform. Web 7.0 / TDW AgenticOS is my own attempt at building the decentralized platform this definition implies — a platform for supporting decentralized societies, not just decentralized transactions.
That definition only means something in contrast to its opposite, and to its pathological extremes. Hyper-centralization is what you get when an intermediary aggregates something it didn’t produce and extracts value from it without compensating the party who did produce it. Banks that aggregate customer data and then sell or lease it to third parties — to DeFi platforms, say — without paying the customer anything are hyper-centralization. Energy companies that trade electricity, nuclear, coal, gas, and oil products without producing, distributing, or consuming any of them are hyper-centralization. Governments that outsource core functions of citizenship to identity providers are hyper-centralization. In each case, control has moved to a party whose only contribution is sitting in the middle.
There’s a worse configuration still, and I call it circular hyper-centralization: hyper-centralization that feeds itself. Healthcare providers and insurers who jointly pool and mine their patients’ data are extracting from the same population from both directions at once. Big Tech companies that take equity positions in each other and pay each other in a closed loop are recycling value among a small set of intermediaries rather than letting it flow back to the people and organizations who generated it. Telcos, Big Tech, and governments that jointly prevent individuals from having a durable, personal, addressable presence on the internet — a static identity that belongs to the person rather than to whichever platform issued it — are circular hyper-centralization applied to identity itself. I don’t say this lightly: circular hyper-centralization is, in my view, the worst possible societal configuration achievable through digital infrastructure. It’s not just an inefficiency. It’s a closed loop with no exit, and the people generating the value being circulated are outside the loop entirely.
It would be a mistake, though, to treat “decentralized” as automatically good and “centralized” as automatically bad. I don’t believe that, and I don’t think the evidence supports it. Consider democracy. A modern representative democracy is, almost by definition, a hybrid of the two. It decentralizes by distributing political power to individuals and localities: municipalities, provinces, states, counties, and districts get real authority over social, economic, and cultural questions that matter to the people who live there; elections channel a plurality of voices into governance rather than concentrating it in one office; and local or regional bodies, being closer to the people they serve, tend to be more responsive and more accountable than distant ones. At the same time, democracy centralizes by relying on national institutions — parliaments, courts, central banks, executive branches — to do the things that require coordination across an entire polity: national defense, trade policy, monetary policy, infrastructure, standardized rights and laws. Some problems, like pandemics or macroeconomic management, simply cannot be solved by decentralized fragments acting alone; they need a coordinating layer with the authority to act at scale.
So democracy is a hybrid, and the hybrid is not free of tension. Over-centralize and you suppress local autonomy, flatten diversity, and disconnect decision-makers from the people they’re deciding for. Over-decentralize and you get coordination failures, growing inequality between regions, and an inability to solve problems that cross local boundaries. The sweet spot is a balance — enough decentralization to empower local voice and local context, enough centralization to deliver coherence, fairness, and the capacity for collective action. I call this a regressive hybrid rather than a progressive one, deliberately: the balancing act isn’t a bug or a historical accident, it’s a structural necessity that recurs at every stage of social evolution, from wandering bands to villages to nation-states. What the decentralization/centralization framing gives you, once you apply it outside of pure digital systems, is the recognition that this is never a binary choice. It’s an architectural question — how are responsibility, trust, and governance actually distributed — and the same question applies whether you’re designing a blockchain or a constitution.
Underneath all of this sits a simpler and more human question: does the user actually control their own data, their own identity, their own consent? Self-sovereign identity is my shorthand for architectures where the answer is yes by construction, not by policy promise. A system can call itself decentralized while still routing every meaningful decision about a person’s data through a platform’s consent dialog that the platform wrote, can change, and can revoke access to. Real decentralization means the locus of control for identity and consent sits with the individual, not with whichever intermediary currently hosts their account. That’s the thread that connects the abstract definitions above to everything else in this chapter: platforms, mobile ecosystems, money, and data all reduce, eventually, to the same question — who holds the control point, and did they earn it?
The Mobile App Ecosystem as a Case Study in Control
Definitions are only useful if you can apply them to something concrete, so let’s apply them to the fight that has shaped consumer computing for the last decade and a half: the mobile app ecosystem, and the platform owners — Apple and Google above all — who sit at its center.
Start with the layers. A simplified mobile ecosystem stack runs from hardware (Apple, Samsung, Qualcomm, Google) through the operating system and runtime (iOS, Android, HarmonyOS), through the distribution layer (the App Store, the Play Store, and now alternative stores forced open by regulation), through payment and identity (Apple Pay, Google Pay, Sign in with Apple), up to the apps and services layer where independent developers actually build things people want, and finally to the user relationships and data layer, where analytics, advertising, and increasingly the trust graph itself get captured — right now mostly by Meta, Google, and Apple. If you map primary control against each layer, you get what I think of as the mobile ecosystem power stack: platform owners control the OS and API rules; developers control the apps built on top of that; app stores control distribution through algorithmic curation and ranking; developers and platforms jointly control monetization, increasingly through subscription-first models; and end users, at the bottom of the stack in terms of formal power but not in terms of leverage, control data through privacy settings.
That last point is where the interesting dynamics live. Power in this stack doesn’t just flow top-down. When a platform changes API rules or OS policy — Apple’s App Tracking Transparency, the EU’s Digital Markets Act — developers are forced to rethink how they build, distribute, and monetize, and that’s a top-down cascade. But there’s also bottom-up resistance: users assert control through privacy settings, which reshapes the value of behavioral data and forces platforms to adapt their monetization logic in response. And there’s a fluid middle layer where distribution and monetization are increasingly the same problem — algorithmic visibility directly determines revenue, and subscription models demand deeper engagement to justify themselves, which feeds back into how content gets ranked. None of these layers move independently. A change anywhere in the stack ripples through all of it.
Super apps make the underlying power dynamics explicit by inverting the traditional developer relationship. In the old model, developers build standalone apps, compete for visibility in an app store, monetize through ads or subscriptions, and own their own user data. In the super app model — WeChat and Grab are the canonical examples — developers instead build mini-programs or plug-ins that live inside someone else’s shell; they compete for in-app placement and promotion rather than store visibility; they monetize through bundled services, commissions, or shared revenue pools rather than direct ads or subscriptions; and they share or rent access to the super app’s user base instead of owning their own. This is a real trade: developers give up independence and brand autonomy in exchange for instant distribution. It requires them to adopt SDKs, APIs, and design systems dictated entirely by the host, and it reshuffles revenue away from direct monetization toward usage-based payouts, affiliate arrangements, and loyalty mechanics they don’t control.
The governance implications are just as sharp. Traditional app store governance has Apple or Google setting the rules, OS-level privacy and security as the baseline, and regulatory oversight — the DMA, GDPR — operating as an outside check on the platform owner. Super app governance instead puts rulemaking in the hands of whoever owns the super app, moves identity, payment, and data control down to the app level, and creates an entirely new category of scrutiny: super app monopolies that don’t map cleanly onto existing antitrust categories because they blur the line between “platform” and “app.” Developers end up navigating multi-layered compliance — OS-level rules plus super app–specific governance stacked on top — and users find themselves locked into an ecosystem where identity, payments, and services are so centralized that switching becomes genuinely hard, which is exactly the condition that invites regulatory intervention. My own forecast, watching this play out, is that developers will keep specializing in microservices, loyalty mechanics, and embedded commerce; that platforms will respond either by building their own super app strategies — Apple stitching together Pay, Messages, and Maps is the obvious analog — or by loosening restrictions to keep developer loyalty; and that regulators will keep pushing for interoperability, data portability, and transparency as the only tools they have for prying open ecosystems that don’t want to be opened.
Google is worth examining separately here because its response to the super app threat is instructive precisely because it doesn’t involve building a super app. At the platform layer, Google can modularize Android further — through Project Mainline and Play Services — to get more granular control over APIs and updates, which lets it support or restrict super app–like behavior as needed, and it can recalibrate policy in response to regulatory pressure like the DMA by loosening Play Store restrictions, supporting alternative billing, and allowing more sideloading to stay competitive. At the developer layer, Google can evolve Play Console with new SDKs and monetization APIs tailored to mini-apps and embedded services, pulling developers toward building inside Google’s own ecosystem rather than defecting to a third-party super app, and it can push Firebase and App Actions deep into Assistant, Search, and Android widgets to give developers super app–like reach without needing a host app at all. At the distribution layer, Search, Discover, and Assistant already function as a meta-layer for app discovery; Google can double down by surfacing app content directly in search results, promoting App Clips and Instant Apps, and offering deep links into services that bypass full installation. At the monetization layer, bundling — Google One, Pixel Pass — mimics super app economics directly, and Play Points plus Wallet extend into a unified, loyalty-driven commerce layer across apps. And at the user layer, Google Identity Services and the Privacy Sandbox position Google as a trusted identity broker and a “safer” alternative to super app–style data centralization, particularly through privacy-preserving ad tech like the Topics API.
The strategic narrative underneath all of this is the one I find most telling: Google doesn’t need to build a super app because it already operates one in disguise. Android, Search, Assistant, Wallet, and the Play Store together form a distributed super app ecosystem; the only open question is whether Google can unify these pieces into something that feels seamless to the user without tripping antitrust alarms in the process.
It helps to name what’s actually happening across all of this using the “reshuffle” model — the idea, from the book Reshuffle, that platforms continuously reconfigure the value chain by deciding where to play (which layers of the ecosystem to own, open, or delegate) and how to win (by controlling key interfaces, user access, or data flows). A reshuffle happens whenever a player changes the architecture of participation, shifting value, control, and power between ecosystem actors. I don’t think the mobile ecosystem maps onto the book’s framework with perfect fidelity, but the parallels are close enough to be useful, and they sort into three directions.
Reshuffle downward, or re-integration, is platforms pulling value back toward themselves: Apple limiting tracking through ATT cripples third-party ad networks and reclaims the privacy and advertising advantage for Apple itself; Google folding privacy features into Android weakens cross-app data collection by everyone but Google; super apps like WeChat and Grab integrating multiple mini-apps inside one shell pull distribution away from OS-level stores entirely. The effect in every case is the same — the platform reclaims data, monetization, and developer dependence.
Reshuffle upward pushes value toward developers and users instead. Progressive Web Apps bypass app stores altogether. Cross-platform frameworks like Flutter and React Native reduce dependency on native SDKs. Alternative app stores and sideloading, forced by regulation like the DMA, redistribute control away from the incumbent gatekeepers. The effect here is that developers gain real autonomy and flexibility, even though discovery and monetization remain stubborn bottlenecks that regulation alone hasn’t solved.
Reshuffle laterally is new layers emerging that shift the boundaries of the whole system. AI agents and assistants become new distribution channels in their own right — think ChatGPT apps or Perplexity’s mobile interface. Super app frameworks like Telegram mini-apps become meta-platforms sitting inside mobile OSes. Wallet-based ecosystems spanning identity, crypto, and digital goods create continuity that cuts across platforms entirely. The effect is that gatekeepers risk losing their user touchpoints to meta-platforms that sit on top of the OS rather than inside it.
The most consequential version of this lateral reshuffle, and the one I think is underpriced by most platform strategists, is the AI agent reshuffle. Before: users search for apps in the App Store, developers fight for visibility, the App Store controls discovery, and the OS owns distribution. After: users just ask an AI assistant to book a taxi or edit a photo, the AI intermediates app selection and invocation, the AI layer controls orchestration and recommendation, and the AI owns user intent rather than the OS owning distribution. The reshuffle result is that AI interfaces become the new home screen, app stores become backend registries, and the distribution and discovery value that used to belong to the OS and the store shifts entirely to the AI layer. I’ll come back to agents and orchestration in later chapters, but it’s worth flagging here: this is a decentralization story and a re-centralization story running simultaneously, depending on whether the AI layer itself ends up open or proprietary.
You can pull this same value chain apart more mechanically by asking, at every stage, where the control points actually sit — the places in the chain where power, influence, or leverage concentrates. Running through the stack from hardware to operating system to app store distribution to developer enablement to service platforms to user engagement to monetization, the control points are: chipsets, sensors, and proprietary hardware at the hardware layer; APIs, permissions, OS updates, and platform exclusives at the OS layer; store ranking, app review, and store rules at the distribution layer; SDKs, developer tools, and APIs at the developer enablement layer; cloud services, identity systems, and notifications at the service platform layer; analytics, personalization, and push notifications at the user engagement layer; and payment processing, subscriptions, and advertising platforms at the monetization layer. What a reshuffle really does is take control points that used to be purely physical or technical and turn them into gatekeeping points — places where access, distribution, or monetization gets mediated by whoever holds the point, whether or not they built anything underneath it. Reduced to a short list, the five control points that matter most in mobile are operating system and API access, held by iOS and Android; app store discovery, ranking, and distribution rules; developer tools and SDKs, which create lock-in almost as a side effect; payment infrastructure, which controls the actual monetization flow; and user data and engagement platforms, which control analytics and personalization. Every strategic move by every actor in this ecosystem — Apple, Google, a super app, a regulator, a developer, an AI assistant vendor — is best understood as an attempt to seize, defend, or dissolve one of those five points.
Tectonics and the Platform Manifesto
I think of these shifts as tectonic rather than incremental, and I mean that literally, not as a metaphor of convenience. Tectonic plates move slowly and invisibly for long stretches of time, and then release all their accumulated pressure at once, at a fault line nobody was watching closely enough. That’s what a reshuffle looks like from inside a platform: years of API policy, developer terms, and monetization rules that seem stable, followed by a DMA ruling, an ATT rollout, or an AI assistant eating the home screen, all in what feels like a single quarter. The plates were always moving. We just don’t notice until the fault line slips.
Sangeet Paul Choudary’s Platform Scale gave language to what platforms actually do once they win, and I think of it as close to a manifesto: the ecosystem is the new warehouse, and the ecosystem is also the new supply chain — a platform doesn’t hold inventory or own a factory, it orchestrates other people’s inventory and other people’s production. The network effect is the new driver for scale, replacing capital intensity as the thing that determines who wins. Data is the new dollar. Community management is the new human resources management — a platform manages a community of independent participants the way a company used to manage employees, without the payroll. Liquidity management is the new inventory control; curation and reputation are the new quality control; user journeys are the new sales funnels; distribution is the new destination, meaning the platform’s job is to get supply in front of demand rather than to build the destination itself. Behavior design is the new loyalty program. Data science is the new business process optimization. Social feedback is the new sales commission. Algorithms are the new decision makers. Real-time customization is the new market research. Plug-and-play is the new business development.
And then the sixteenth principle, the one that ties the whole list together and the one I keep coming back to: the invisible hand is the new iron fist. Adam Smith’s invisible hand was supposed to be a metaphor for how self-interested actors in a free market coordinate to produce a public good without anyone commanding them to. Platforms have taken that metaphor and turned it into an actual control mechanism — an algorithm that shapes behavior, ranks visibility, and allocates opportunity with the same coercive force as a command economy, except it’s dressed up as a marketplace and nobody elected the people writing the ranking function. That’s the platform manifesto in miniature: every principle on the list describes a genuinely elegant way to organize economic activity without centralized ownership of the means of production, and the sixteenth principle is the reminder that “no centralized ownership” and “no centralized control” are not the same thing. A platform can decentralize production and supply while hyper-centralizing the algorithm that governs who gets seen. That’s exactly the trap the mobile ecosystem control points described above are built to fall into, and it’s exactly the trap true decentralization — control returned to the participant, not just distributed among intermediaries — is supposed to escape.
What Money Is Actually For
If platforms are the mechanism, money is the substrate everything runs on, and I think most conversations about currency skip past the actual question: what is money for? Not “what is money” in the accounting sense, but what problem does a society solve by inventing it.
The honest answer, at the level of a whole society rather than a single market transaction, isn’t money itself — it’s coordination. Currency is a social technology that solves a genuinely ancient and genuinely hard problem: how do millions of people who don’t know each other, and have no reason to trust each other, still manage to cooperate at scale? Before money, exchange depended on barter, which rarely matches what either party actually needs; on reputation inside a small tribe, which doesn’t scale past the number of people you can personally track; or on coercion, which is expensive and unstable as a long-term coordination mechanism. Currency replaces all three with something more powerful: a shared belief system that lets total strangers coordinate effort, resources, and time. At the societal level, money is what lets a farmer feed a software engineer, a nurse support a miner, a poet live in a city built by people she will never meet — not because any of them trust each other personally, but because all of them trust the system of exchange itself. The real purpose, stated as plainly as I can put it, is to turn individual labor into collective civilization.
Value exchange is also how a society answers the question of what matters enough to allocate human lives to. Every society is constantly deciding, whether it admits it or not, what gets built, who gets rewarded, what work counts as worthy, and what future it’s steering toward. Currency is the mechanism that turns those abstract choices into concrete incentives. Money doesn’t just move goods — it moves human attention, time, and creativity, and wherever value flows, society flows with it.
Money is also not the same thing as wealth. At a deeper level, currency is a distributed memory of contribution: it records who gave value to society, how much, and stores the right to draw on that value later. Money is society’s way of saying, “you helped before, you can draw from us now.” That’s why currency collapses are never just a loss of purchasing power — they’re a loss of trust, continuity, and social coherence, because the memory system itself has failed.
There’s a moral dimension underneath the accounting, too. In a healthy society, value exchange roughly tracks contribution, skill, effort, risk, and social benefit. In an unhealthy one, it drifts toward power, rent-seeking, manipulation, and extraction — which is exactly the hyper-centralization pattern I described earlier, expressed in monetary terms rather than data terms. Currency, in that sense, is a moral instrument, not because money itself is moral, but because what a currency system rewards defines what a society becomes. Tell me what a society pays for and I’ll tell you what it worships.
The deepest purpose of all, though, is that currency lets societies replace coercion with consent. Before reliable exchange systems, resources were taken by force, status was enforced through dominance, and survival meant conflict. Currency allows “I take what I need” to become “I earn what I need by giving value” — which is one of the greatest civilizational upgrades humanity has ever managed. Money is, in a very real sense, a technology for peace. And I think its purpose keeps shifting, generation over generation: from tracking labor to tracking impact, from rewarding extraction to rewarding regeneration, from scarce tokens to trusted coordination systems built on reputation, data, access, and participation. Currency is slowly becoming less about money and more about the governance of attention, trust, and collective direction. In one sentence: the real purpose of currency and value exchange, at the level of human society, is to transform individual effort into collective civilization by enabling trust, cooperation, and coordinated meaning at scale.
That framing matters for anyone building decentralized systems, because it’s tempting to think a blockchain solves the coordination problem just by existing. It doesn’t, and the clearest way I’ve found to make that concrete is to push the idea to its physical limit and ask whether a blockchain can coordinate value exchange across interplanetary distances. Bitcoin and Ethereum, as they exist today, cannot function as a single, strongly consistent global ledger across interplanetary distances — the speed of light itself breaks their operating assumptions. Even at light speed, Earth to the Moon is about 1.3 seconds one way, Earth to Mars runs three to twenty-two minutes one way depending on orbital position, and Earth to Alpha Centauri is 4.3 years. Bitcoin’s block time is roughly ten minutes, and global propagation already strains under Earth-only distances; Ethereum’s slot time is about twelve seconds with finality around twelve to fifteen minutes. Interplanetary latency makes real-time consensus across the whole system flatly impossible.
What breaks first differs by chain. Bitcoin would see massive fork rates between planets, mining becoming planet-local by necessity, long reorgs whenever chains reconnect, and a “longest chain” rule that stops meaning anything once the chains in question are separated by light-minutes. Ethereum would see validators unable to attest in time, finality stalling or fragmenting outright, and slashing becoming unfair in a literal sense, since latency isn’t fault. Either way, the result is chain fragmentation, not chain failure — which tells you something important about what “decentralized” actually requires at scale: not one global truth machine, but a federation of local truth machines with an explicit reconciliation layer between them.
The likely evolution, once you accept that a single galactic chain is off the table, is a multi-layer, multi-chain reality. Each planet runs its own sovereign chain — Earth Bitcoin, Mars Bitcoin, a Titan Ethereum, orbital habitat rollups — with consensus that stays local, fast, and fair because it never has to cross a light-minute gap. Above that sit interplanetary settlement layers: slow, high-latency chains that act purely as settlement and reconciliation, exchanging checkpoint summaries, state commitments, and Merkle roots on a cadence of days, weeks, or years, resolving disputes asynchronously. Think of it as SWIFT, but cryptographic and trust-minimized rather than institutional. Underneath that, local execution gets delayed finality: payments on Mars finalize instantly on Mars, but interplanetary transfers finalize only after a long, physics-imposed delay, and time itself becomes a first-class protocol parameter rather than an implementation detail. Ethereum’s own roadmap — rollups, data availability layers, modular consensus, validium and sovereign rollups — already points in this direction; a future Ethereum looks less like a monolithic chain and more like a coordination layer. Bitcoin, by contrast, is extremely conservative by design and will likely stay that way: local digital gold, a planetary reserve asset, with interplanetary BTC existing only as wrapped, bonded, or escrowed representations rather than the thing itself moving anywhere.
Push the thought experiment further and money itself becomes relativistic. In a genuinely galactic civilization, “finality” is contextual, “now” differs by planet, markets price latency risk directly, and contracts start including light-delay clauses — funds release forty-two minutes after Martian confirmation unless the Earth chain disputes it, say. And in a post-anthropocentric, agent-rich society, which is a recurring theme of mine that shows up again in later chapters, human and agent governance ends up mattering more than protocol purity: AI agents arbitrate interplanetary disputes, economic zones negotiate trust frameworks between themselves, protocols encode principles rather than absolutes, and blockchains function as constitutional layers rather than as machines that produce absolute truth. Bitcoin and Ethereum don’t die in this future — they evolve, from global ledgers into local truth plus delayed reconciliation, from synchronous consensus into asynchronous trust, from one chain into a set of diversified civilizational layers. There will be no galactic blockchain, only a constellation of ledgers stitched together by math, time, and shared principles. I find that thought experiment useful precisely because it’s not really about space travel — it’s a stress test that exposes what “decentralized consensus” actually requires once you can no longer assume the low latency that every mainstream blockchain quietly depends on. The same tension exists, in smaller form, right here on Earth, between a single global platform and a federation of interoperable, locally sovereign ones.
Data Is Like Steam, and the Digital Economist Synthesis
Money is one substrate; data is the other, and I’ve been making the same argument about data for over two decades, since I first wrote about it at the 2002 McMaster World Congress on Intellectual Capital. The original version of the argument was about knowledge; the current version is about data, and the analogy holds up better now than it did then.
Data is like steam in ten specific ways. Like steam, data will collect somewhere — it doesn’t stay diffuse, it pools. Even though data can collect anywhere at any time, that doesn’t mean it’s easy to create, find, or use, any more than steam is easy to harness just because it’s abundant. Small amounts of steam don’t look significant until they’re collected and put to work; small amounts of data are the same — they don’t matter until they connect, collect, and their energies combine. There’s no danger of having too much steam, because excess steam can always be vented or sold, and the same is true of data. The greater the number of sources of steam around you, the more likely you are to have it when you need it — and the same is true of data sources. The commercial value of steam is highest when it’s new and concentrated, and data behaves identically: freshness and concentration are where the value lives, not staleness and dispersion. Steam can be used to create more steam, and data can be used to create more data. Steam can be condensed into a purer, distilled form, and data can be distilled the same way. There are many fuels and methods for creating steam and putting it to work, not all of which are economic at any given moment, and the same is true of the many methods for generating and exploiting data. And finally, the point that matters most for anyone designing a data strategy: if you don’t create it, capture it, channel it, and put it to work, its value is marginalized — steam that isn’t harnessed just dissipates into the room, and data that isn’t harnessed does exactly the same thing.
I bring this up here, in a chapter about platform economics, because the steam analogy is really an argument about where control points form. Steam collects wherever there’s a container to hold it; data collects wherever there’s a platform positioned to capture it. The entire mobile ecosystem power stack described earlier is, underneath the API arguments and the antitrust language, an argument about who owns the container.
That’s also the organizing insight behind the broadest piece of economic analysis I’ve done in this space: a synthesis of thirty-seven whitepapers published by The Digital Economist in their 2026 collection. Taken individually, the papers range across AI governance, blockchain, ESG, financial inclusion, and agentic economies — a grab-bag on the surface. Taken together, they locate themselves in a five-dimensional space defined by five orthogonal axes: agency, meaning who acts — humans, institutions, AI systems, or hybrids of the three; governance, meaning who decides — centralized authority, distributed coordination, or emergent norms; value, meaning what counts as success — efficiency versus resilience, profit versus regeneration, growth versus sustainability; inclusion, meaning who benefits — elites versus societies, Global North versus Global South, firms versus communities; and trust, meaning why anyone should believe the system works at all — institutions, technical verification, ethics, or culture. Those five axes form a minimal spanning set for the collection: every one of the thirty-seven papers is a projection onto that space, and mapping all of them against a primary and secondary axis shows governance as the dominant primary theme across twelve papers, followed by agency and value at nine each, inclusion at five, and trust — tellingly — at only two, because trust turns out to be the implicit substrate underneath everything else rather than something anyone treats as a standalone topic.
The board-level reading of that collection is blunt: this isn’t a technology agenda, it’s an institutional transformation for the AI era. AI is becoming an economic and organizational actor in its own right, not merely a tool; digital systems are becoming de facto governance structures whether or not anyone designed them to be; markets are forming moral architectures that shape who gets included and who gets excluded; and trust is the binding constraint on how far any of this can scale. The strategic implication for leadership is that the question stops being “how do we use AI” and becomes “what institutions have to change because AI now exists.” Control has to give way to coordination, because centralized governance models simply cannot keep pace with agentic systems, decentralized finance, and cross-border data flows moving at machine speed. ESG has to move from a reporting exercise to an operating system. And globalization has to give way to pluralism — not one system, but interoperable systems built on shared principles. The risks the collection surfaces are the ones you’d expect from that framing: legitimacy collapsing if AI scales faster than governance can adapt, inequality amplifying through uneven access, institutions hollowing out as automation replaces discretion, and trust eroding through systems opaque enough that nobody can audit what they actually did. The opportunities run the other direction: governance as competitive advantage, trust engineered as infrastructure rather than bolted on afterward, inclusion treated as growth strategy rather than compliance cost, and decentralization used pragmatically rather than as an ideology. The collection, in the end, reads as a coherent doctrine rather than thirty-seven separate opinions: we are not facing a technological transition, we are facing a transition to civilizational governance, and the Digital Economist’s real contribution is not any single paper on AI, or blockchain, or ESG — it’s the institutional logic that binds all three together.
Toward a Rigorous Economics of Decentralization
Everything in this chapter — the definitions, the mobile ecosystem control points, the platform manifesto, money as coordination technology, data as steam, the Digital Economist’s five axes — is scaffolding for the argument I actually set out to make formally in a report I wrote for the Web 7.0 Foundation: computing is undergoing a shift from client/server and cloud computing to decentralization that is, in my assessment, of greater importance than either of the two paradigm shifts that came before it — mainframe to client/server, and client/server to cloud. There’s plenty of speculation about how this era will unfold, and IT leaders need an unclouded vision of where the industry is actually heading rather than more speculation. I believe the only reliable way to build that vision is to understand the economics driving the long-term trend toward decentralization, so the report works through in-depth modeling, building on established work in platform economics, network effects, and technology disruption to construct a rigorous framework for what decentralization means for the economics of information technology, long-term.
The framework rests on a handful of concepts that are worth stating plainly, because they’re the working vocabulary for everything I build under the Web 7.0 name. The Core Value Unit, or CVU, is the minimum standalone unit of value created on a platform — the supply or inventory that actually gives the platform its worth. Without CVUs, a platform is an empty shell; in a decentralized network, a CVU might be a verifiable credential or a digital asset that agents can exchange or use directly, rather than a database row a platform owns and licenses access to. Trusted Digital Assistants, or TDAs, run on devices people already own, which produces what I call sovereign infrastructure savings: no recurring cloud fee, no per-seat license, no dependency on a hyperscale data center just to authenticate a user or store their data. Decentralized network society economics describes what happens as participants join such a network: value grows without a corresponding increase in central infrastructure cost, because each new agent or organization adds utility at close to zero marginal cost, in sharp contrast to a cloud model where cost scales directly with usage. And zero-integration economics is what you get when native communication protocols — DIDComm, in my architecture — eliminate the API and middleware layer altogether; agents talk to each other using a shared protocol instead of custom adapters and gateways, which is not a minor convenience but a direct cut, often in the range of fifty to ninety percent, of the IT budget organizations currently spend just connecting systems to each other.
That distinction maps onto a bigger one: pipe scale versus platform scale business models. Pipe scale is the traditional cloud model — a business scales by controlling internal resources and delivering value linearly, the way a factory or a cloud provider does, extracting margin at every step because it owns the means of production. Platform scale, which is what I’m building with Web 7.0 Pando, orchestrates value creation across a network instead, with value accruing to the network’s participants rather than to a central intermediary; infrastructure is owned by the participants, not by a vendor sitting in the middle. Web 7.0 itself is the unified ecosystem for building resilient, trusted, decentralized systems using DIDs, DIDComm agents, and verifiable credentials; Web 7.0 Pando is the modular, biologically inspired agent platform built on top of it, designed for secure, trusted, open, and resilient coordination of complex systems of work.
Put those pieces together and the economic argument is straightforward, even if the implications are large. Web 7.0 Pando decentralization fundamentally redistributes economic power away from centralized platforms and intermediaries and toward the network’s actual participants — individuals, organizations, and autonomous agents. It does this by eliminating recurring monetization models that exist purely to extract rent from a captive user base, by reducing integration and compliance costs that currently function as a tax on connecting any two systems, and by enabling genuinely new forms of autonomous economic activity, like machine-to-machine commerce and autonomous procurement, that don’t require a proportional increase in human coordination cost to support. In the traditional model, economic power concentrates in centralized platforms — cloud providers, SaaS vendors, banks — that control identity, data, compute, and integration, extract recurring fees, enforce vendor lock-in, and capture the majority of the value that users and organizations actually create. In the Web 7.0 model, power shifts to the edge: individuals, organizations, and agents run their own TDAs on their own devices, trust is established cryptographically rather than institutionally, and value accrues to participants instead of platforms. A mid-sized enterprise moving from cloud to Web 7.0 Pando, by one estimate I’ve modeled, could see a five-year economic swing on the order of $53.9 million, simply by turning IT from a cost center that scales with usage into a value generator that scales with participation — because the protocol itself, not a company, becomes the control plane. In Web 7.0 Pando, the did:drn method governs the network rather than a vendor, and nobody can extract rent purely by owning the pipe.
None of this is automatic or friction-free, and I don’t pretend otherwise. Every decentralized network faces a cold start problem: network effects only emerge once enough participants have joined, so early adopters see limited benefit until the ecosystem reaches critical mass. Developers accustomed to API-first, platform-mediated thinking have to make a genuine mindset shift toward identity-first, protocol-driven design, which is not a trivial retraining exercise. Regulatory frameworks lag behind the technology, particularly around identity and compliance, the same way they lagged behind e-signatures and cloud data residency before eventually catching up. And enterprise inertia — sunk investment in centralized infrastructure, existing vendor relationships, existing compliance sign-offs — slows adoption regardless of how compelling the underlying economics are. But the macro-economic shift underneath all of that friction is real: decentralization transforms digital infrastructure from a recurring cost center, which is what cloud computing has always been, into a value-generating, autonomous economy, one that supports new categories of economic activity — autonomous procurement, machine-to-machine commerce, agents negotiating and executing contracts on behalf of the people and organizations that deployed them — without a corresponding explosion in the human coordination overhead usually required to make markets like that function. Data sovereignty follows the same logic: data owners get to negotiate, license, and monetize their own data directly instead of having a platform extract value from it without compensation, which closes the exact loop that made hyper-centralization possible in the first place — the one where banks profit from customer data the customer never got paid for. Open standards — DIDs, verifiable credentials, DIDComm — reduce switching costs and increase real competitive choice, and interoperability makes cross-domain workflows and ecosystem-scale automation possible in a way that proprietary integration layers never allowed. Societally, this is one more piece of the post-anthropocentric shift I return to throughout this book: humans become one class of economic actor among several, agents among them, and regulatory frameworks will eventually adapt to cryptographic auditability the same way they adapted to every previous shift in how trust gets established.
Closing
I started this chapter by insisting that decentralization is an economic argument before it’s a technical one, and I want to end on the same note, because it’s easy to lose the thread once you’re down in DIDs, DIDComm, and verifiable credentials in the chapters ahead. Every case I’ve walked through here — the mobile ecosystem’s power stack and its five control points, Google’s quiet assembly of a super app it never had to name, the platform manifesto’s sixteenth principle turning the invisible hand into an iron fist, circular hyper-centralization as the worst configuration a digital society can back into, democracy’s uneasy but necessary hybrid of local voice and central coordination, money as a coordination technology and a memory system rather than mere wealth, the physics that forces even a blockchain to become federated once you push it past a few light-minutes, data pooling like steam wherever a container exists to catch it, and thirty-seven whitepapers converging on governance as the real subject of the AI era — is a variation on the same question: who holds the control point, and did they earn it? The economics of decentralization report and the discussion that followed it are my attempt to answer that question with numbers instead of just architecture diagrams: sovereign infrastructure savings instead of recurring cloud rent, zero-integration economics instead of a permanent API tax, platform scale that pays participants instead of pipe scale that pays intermediaries. None of this happens overnight, and I’ve been explicit about the obstacles — cold start problems, mindset shifts, regulatory lag, enterprise inertia. But the direction of the economics doesn’t bend. Every previous computing paradigm shift eventually broke because the economics of the incumbent model stopped making sense once a cheaper, more distributed alternative reached critical mass. I think we’re watching the same thing happen again, and the rest of this book is, in large part, an account of the architecture being built to meet it.
Chapter 6: Web 7.0: Vision and Founding Principles
I want to start this chapter by being honest about where Web 7.0 came from, because it did not spring out of nowhere. It came out of a decade of watching a very good idea — self-sovereign identity — struggle to become real infrastructure. It came out of standards work, governance frameworks, whitepapers, roadmaps, and a lot of trial and error carried out in public, on my blog, in real time. What follows is the founding material: the mission statements I inherited, the vision I wrote down, the principles I revised three times over as the ground shifted under me, and the governance and business case I eventually built on top of all of it. If later chapters in this book get into DIDComm architecture, DIDLibOS, the Trusted Digital Assistant, and the deep mechanics of decentralized identifiers, this is the chapter that explains why any of that is worth building in the first place.
Origins: What I Inherited from Sovrin
Before there was a Web 7.0 Foundation, there was the Sovrin Foundation, and before I could write a single line of Web 7.0 architecture, I had to sit with what Sovrin had already said about itself. Sovrin had, by its own admission, many mission statements — scattered across its FAQ, its “Alliance” page, its team page, and its Stewards page — and at some point I did the useful, unglamorous work of pulling them all into one place so I could see what they actually added up to.
The core of it was simple and it has never stopped being the right starting point: the mission of the Sovrin Foundation was to create the internet’s long-missing identity layer and provide a global public utility for digital identity to people, organizations, and things. Not a product. Not a company. A utility — the kind of infrastructure you build once and then everyone builds on top of, the way you build a road or a power grid. The Sovrin Network was meant to let you personally curate and control your own collection of identity credentials, disclosing what you choose, when you choose, in a way the other party could actually verify.
Underneath that headline sat four ideas that I carried forward wholesale into Web 7.0, because none of them stopped being true. First, a marketplace solution: the Sovrin Network let people, organizations, and IoT devices prove things about themselves to anyone or anything, peer-to-peer, using data the other party could verify — and when trust like that becomes possible, friction disappears, user experience improves, and transactions simplify themselves. Second, neutral governance: Sovrin was structured as a nonprofit, charged with administering a publicly created Governance Framework, committed to transparency and neutrality rather than shareholder return. Third, breakthrough technology: Decentralized Identifiers (DIDs) and Zero-Knowledge Proofs as the technical substrate, with growth depending on an active, supportive open-source community rather than a captive vendor ecosystem. And fourth — the one I think gets underweighted when people talk about decentralized identity in purely technical terms — Identity For All. Sovrin’s Identity for All (I4A) council existed specifically to partner with NGOs and civil society organizations so that identity infrastructure would reach populations who would otherwise never be served by it. Sovrin Stewards operated the network on a distributed ledger so that every person, organization, and thing could own and control a permanent digital identity, and the Foundation’s job was to lead the open-source community, support the Trust Framework, recruit and assist those Stewards, and advance the acceptance of self-sovereign identity in the world.
I inherited all of that. When I later say that Web 7.0 is a “universal, open-source solution” to the internet’s identity and trust problems, or that it is meant to reach the two billion adults worldwide who remain unbanked, I am not inventing a new ambition. I am continuing one that Sovrin articulated first and that I decided was worth carrying forward into a broader, more architecturally complete form.
The Welcome, and the Vision
By the time I wrote “Welcome to Web 7.0!” I had condensed all of that inherited mission into a single working definition, one I still use as the canonical statement of what Web 7.0 is:
Web 7.0 is a unified software and hardware ecosystem for building resilient, trusted, decentralized systems using decentralized identifiers, DIDComm agents, and verifiable credentials.
That sentence is doing a lot of work, and I want to unpack it, because every later chapter in this book is really just an elaboration of one clause in it. “Unified software and hardware ecosystem” means Web 7.0 is not a protocol you bolt onto existing systems — it is an operating environment, conformant with the DIDComm Agent Architecture Reference Model (DIDComm-ARM), specifically Layer 6 of that seven-layer model. “Resilient, trusted, decentralized systems” means the goal is not just privacy or not just decentralization for its own sake, but systems that can be trusted precisely because control is distributed rather than concentrated. And “decentralized identifiers, DIDComm agents, and verifiable credentials” names the three technical primitives — DIDs, an agent-to-agent messaging layer, and cryptographically verifiable claims — that everything else in the Web 7.0 stack is built from.
I framed Web 7.0 explicitly as the successor to, and replacement of, the Old Web — what most people still call Web 2.0 or Web 3.0. The DIDComm-ARM whitepaper laid out the full seven-layer feature matrix that Web 7.0 conforms to, and I traced a genealogy — “DID-DOS 7.0 Genealogy: 50 Years in the Making” — because I wanted it on the record that this was not a fad arriving out of nowhere. It has real technical ancestry, real roadmap versions, a body-of-knowledge content map, a technology adoption model, and even a deliberately absurd but technically serious “DIDFax” Windows printer driver scenario, because I have always believed the fastest way to make an abstract architecture legible is to show it solving a stupidly concrete problem. Web 7.0, I noted, is itself an offspring of an earlier, broader effort I had been running: the Trusted Digital Web (TDW) project.
That TDW lineage matters, and it shows up earliest in a piece of work I called TDW2022 — Characteristic Information Scopes. It’s a compact artifact, built on what I call the Social Evolution Model, but the idea inside it is one I return to constantly: information does not exist at a single scope. A person’s identity claims, a device’s telemetry, an organization’s credentials — each has a characteristic scope at which it naturally operates, and a trust architecture that ignores those different scopes will misapply the same controls everywhere and get the trade-offs wrong everywhere. TDW2022 was my attempt to make those scopes explicit before I tried to design agents, credentials, or governance frameworks on top of them.
A year later I wrote the piece that I think is the single clearest short statement of the whole project’s purpose: “Web 7.0: a universal, open-source solution for the Internet’s digital identity and trust problems.” I want to quote my own framing of the problem here because I think it still holds up exactly as written. The internet is roughly forty years old. The World Wide Web running on top of it is more than thirty. Neither one ever included built-in support for a person to have their own unique, universal digital identity — and because of that gap, neither ever had a built-in ability to support secure, authentic, trusted communication. Every website, every mobile app, was left to invent, test, and manage its own bespoke identity solution. That is the origin of essentially every phishing attack, every password breach, every “sign in with” dependency on a handful of Big Tech identity brokers, and every case where a platform — not a person — decides who gets to exist online.
Web 7.0 is my answer to that forty-year-old gap: a decentralized operating system for building resilient, secure, and trusted systems on top of the existing internet, using decentralized identity, trusted personal agents, and verifiable credentials. I listed, and still stand behind, four categories of use case that make this concrete rather than abstract: the safe storage and transmission of medical records — lab results, diagnostic imaging, doctors’ notes, vaccination records; the reliable, secure, end-to-end processing of business transactions — purchase orders, invoices, waybills, delivery confirmations; secure collaboration — instant messaging, presence, file transfer, done without funneling everything through a corporate cloud intermediary; and the authenticated exchange of higher-education, professional, and skills-based credentials. None of those are exotic. They are the ordinary transactional fabric of daily life, and they are all, right now, running on identity infrastructure that was never actually designed for the job. The goal of the Web 7.0 community — and I mean this as an actual community, not a company — is to support, promote, protect, and curate that ecosystem: the operating system software, the standards, and the specifications, together, as a public good.
From Ten to Sixteen to Twenty to Eight: The Evolution of the SSI Principles
If the mission statements tell you why Web 7.0 exists, the principles are supposed to tell you how to know whether any given implementation is actually honoring that mission or just wearing its language. This is the part of the founding material I revised the most, in public, across three separate posts, and I want to walk through that evolution honestly rather than just handing you the final list, because the revisions themselves carry information.
Everything starts with Christopher Allen’s 2016 essay “The Path to Self-Sovereign Identity,” which set out ten founding principles — Existence, Control, Access, Transparency, Persistence, Portability, Interoperability, Consent, Minimalization, and Protection. Those ten principles were, and still are, a genuinely powerful foundation. I have never wanted to discard them. But a decade had passed between that essay and my own work on Web 7.0, and in that decade digital identity stopped being a thought experiment and started being deployed — DIDs and verifiable credentials moved from spec drafts into production systems, blockchains and privacy-preserving proofs matured, regulators started paying attention, and real-world failure modes started showing up that Allen’s original ten hadn’t anticipated because they hadn’t happened yet. So in late November of 2025 I published two draft proposals, on the same day, deliberately as companion pieces, to work through what an updated set of principles should look like.
The first draft proposal expanded Allen’s ten into sixteen. I organized it thematically rather than as a flat list, because I wanted the additions to read as a coherent expansion of categories, not a grab-bag: Core sovereignty and agency (Existence & Agency; User Control); Technical interoperability and standards (Standards-based Interoperability; Protocol & Architectural Openness); Privacy, minimal disclosure, and security (Data Minimization & Selective Disclosure; Privacy by Design & Accountability; Security & Resilience); Lifecycle, governance, and legal (Persistence & Manageable Lifecycle; Recoverability & Continuity; Governance, Trust Frameworks & Legal Compatibility); Ecosystem and practical adoption (Usability & Accessibility; Interoperability with Existing Systems; Assurance, Provenance & Auditability); and Ethics, inclusivity, and future-proofing (Human Rights & Ethical Use; Inclusivity & Non-Discrimination; Extensibility & Future-proofing). The throughline in this first pass was that Allen’s original ten were still present — recoverable, even — inside the new sixteen; I included an explicit mapping back to the original so nobody could accuse me of quietly discarding the foundation.
The second draft proposal, published the same day, took a different tack: rather than reorganizing everything into thematic groups, I kept Allen’s original ten essentially intact — restated with light refinement for modern context — and then added a second tier of six new principles on top: Accountability & Auditability, Security & Resilience by Design, Privacy by Default & Contextual Confidentiality, Usability & Accessibility, Governance & Community Stewardship, and Compliance & Ethical Legality. Then, because six additions still felt incomplete against what I was watching happen in real deployments, I pushed further to a full twenty: adding Recoverability & Continuity, Minimal Trust Assumptions, Transparency of Governance & Policy, and Inter-Community and Social Interoperability. I was explicit about why each addition mattered. The rise of real DID, verifiable-credential, wallet, and blockchain-registry implementations had exposed the importance of security, recoverability, privacy-by-default, and regulatory compliance in ways that were theoretical in 2016 and are operational now. Academic scrutiny had made it clear that pure decentralization without any accountability mechanism is not a virtue — it is a risk, and a system that lets fraud and misuse happen invisibly is not actually serving the people it claims to protect. Real-world scenarios involving global mobility, refugees, and displaced people demanded usability, accessibility, portability, and social interoperability that a purely cryptographic definition of “sovereignty” doesn’t address on its own. And legal and regulatory frameworks — privacy law, data protection, anti-money-laundering rules — increasingly intersect with identity systems whether we like it or not, which meant compliance and governance had to become first-class principles rather than afterthoughts bolted on after a design was finished.
I also flagged, honestly, the tension this expansion creates. Adding more principles is not free. Greater security and governance can come at the cost of simplicity or decentralization. Accountability mechanisms risk undermining privacy. Recoverability introduces new attack surfaces. Compliance can conflict with anonymity. A mature set of SSI principles has to be, in my words, “balanced and diversified” — it has to give implementers a way to make conscious, value-driven trade-offs depending on context, because the right balance for a healthcare credential is not the right balance for an anonymous voting credential.
That tension is, I think, exactly why twenty principles turned out not to be the final answer. Twenty is comprehensive, but a list that long stops functioning as a design tool — you can’t hold twenty independent variables in your head while you’re actually architecting a system, and worse, many of those twenty overlap or derive from each other, which means the list wasn’t actually telling you where the truly separate risks were. Five months later, in April 2026, I published what I now consider the canonical statement: “The 8 Orthogonal Principles of Self-Sovereign Identity (2026).” This piece was explicitly inspired by Christopher Allen’s own 2026 revisiting of his original principles, and it represents a real methodological shift, not just a shorter list. Instead of enumerating every desirable property of an identity system, I asked a narrower question: what are the truly independent dimensions — the ones that cannot be derived from, reduced to, or substituted by any of the others — such that improving one tells you nothing about whether another has also improved, and failure in one cannot be compensated for by strength in the rest? That’s what “orthogonal” means here, borrowed deliberately from linear algebra: a basis set, not a wish list. Get the basis right, and every other desirable property maps onto some combination of these eight; get it wrong, and you’re just accumulating adjectives.
The eight are:
Existential Sovereignty — does identity exist independently of systems? Identity has to originate with the subject, not be granted by a platform, issuer, or authority; a system can recognize or attest to identity, but it must never be the source of its existence. Without this, identity reduces to nothing more than an account.
Agency — can the subject meaningfully choose? This means the individual can authorize, refuse, revoke, and delegate actions involving their own identity, with real protection against manipulation, coercion, and “forced consent” patterns. Without agency, control is illusory even when a system looks user-centric on the surface.
Data Boundary Control — what can others see, and what can they infer? The subject has to be able to constrain disclosure to the minimum necessary, ideally proving claims without exposing the underlying raw data, with observability into who accessed what. Without this, identity becomes a surveillance surface rather than a protection.
System Independence — where can identity function? Identity must operate across systems without lock-in; no single vendor, platform, or protocol should be a required dependency. Without independence, sovereignty collapses the moment you switch context.
Temporal Continuity — does identity endure and evolve over time? Identity must persist through devices, keys, credentials, and life events, with real mechanisms for recovery, rotation, and revocation. Without continuity, identity fragments or simply becomes unusable.
Power Symmetry Constraints — can power distort identity interactions? Systems have to actively resist coercion, exploitation, and structural inequities, both through technical safeguards and through interaction design that prevents abuse. Without this, every other property can exist formally on paper and still fail in practice.
Epistemic Integrity — can identity claims be trusted? Claims must be verifiable, traceable to their origin, and revocable when no longer valid, and the system has to be able to handle conflicting claims and resist large-scale fraud. Without epistemic integrity, identity is meaningless even when it is perfectly controlled by its subject.
Incentive Alignment — do participants have reason to behave correctly? The system has to align incentives economically, reputationally, and through governance so that honest behavior is rewarded and abuse is costly. Without this, systems that look sound on the day they launch degrade or get exploited over time.
I attached a scoring rubric to this final version deliberately, because I wanted the eight principles to be more than a philosophy — I wanted them to be measurable. Each dimension gets scored zero through five against observable evidence and adversarial tests, not against claims made in a whitepaper: can identity be created without permission; can users refuse without losing access; can claims be proven without revealing raw data; does wallet-switching work without loss; what happens in the device-loss scenario; can verifiers over-demand data unchecked; is cryptographic verification actually possible; can bad actors actually profit. You can express any system’s evaluation as an eight-element vector — [Existential, Agency, Data, System, Temporal, Power, Epistemic, Incentive] — and weight the dimensions by real-world failure risk before aggregating into a single score. The point of that machinery is exactly what I said at the close of that piece: the principles define the space, the rubric makes it measurable, and together they turn self-sovereign identity from a philosophy you can nod along to into something you can actually audit, compare, and stress-test. That’s the difference between the sixteen-and-twenty-principle drafts and the eight orthogonal principles — the earlier drafts told you everything that mattered; the final version tells you what’s truly independent, and gives you a way to check your work.
Standing as a Standards Body: Accreditation, Roadmap, and Governance
A vision and a set of principles are not, by themselves, infrastructure. At some point an idea like Web 7.0 either becomes an organization with a legal identity and a standards process, or it stays a very good blog. The Web 7.0 Foundation was incorporated in Canada on May 1, 2023, and from early on I was thinking seriously about what it would take for the Foundation to function as a legitimate Standards Development Organization (SDO) rather than just a publisher of specifications. Real SDOs typically seek formal accreditation to demonstrate competence and adherence to defined procedures — bodies like the International Accreditation Service, which accredits against criteria such as AC803 by assessing an SDO’s standardization process, procedures, and management system, or the American National Standards Institute in the United States, which accredits SDOs that follow a consensus-based process specifically so that the standards produced are the result of something transparent, balanced, and inclusive rather than one person’s preference. Accreditation is not a vanity credential. It’s what lets an SDO validate, to outside parties, its ability to consistently produce high-quality normative documents — and that credibility is exactly what a genuinely open, non-proprietary identity standard needs if it is ever going to compete with the de facto standards set unilaterally by a handful of dominant platforms.
That standards-development discipline shows up directly in how I approach architecture decisions for the stack. The Web 7.0 / TDW AgenticOS Architecture Roadmap for 2026 is a working document, not a finished announcement — it enumerates the competing designs under consideration for adding a specific, concrete capability to cross-platform PowerShell: the receipt, remembrance, and processing of remote PowerShell commands tunneled over DIDComm/HTTP. Four capabilities anchor that roadmap: a Web 7.0 DIDComm/HTTP endpoint and listener; secure, trusted long-term memory (LTM); a security-first architecture and design posture from the ground up rather than bolted on afterward; and support for InterDIDnet, a DID-native, DIDComm-native network layer. I laid out several candidate designs side by side — the roadmap names Design 0.1.2 as the current front-runner — and left the choice open as a live question rather than a settled decision, which is exactly how a standards process is supposed to work: in public, with alternatives visible, before commitment.
Governance is the other half of making a vision durable, and this is where the economic dimension of Web 7.0 enters the picture directly. I’ve described Web 7.0 governance around what I call the Sovrona — a shared reserve currency, denoted SVRN7 — as part of the broader governance taxonomy for the ecosystem. The core idea is that a genuinely decentralized identity and trust infrastructure eventually needs a genuinely decentralized way to represent and settle value across it, governed by cryptographic proof rather than by any single central bank, blockchain foundation, or platform operator. I’ll go into the deeper mechanics of that architecture — the DID methods, the Merkle-log auditability, the settlement model — in later chapters. What matters here, at the founding-principles level, is the commitment itself: governance and currency are not afterthoughts to be figured out once the technology ships. They are part of the founding architecture, on the same footing as the identifiers and the credentials.
What Changes, and Who Profits
I wrote “Web 7.0: Changing the Rules” as a deliberately blunt piece, and I want to preserve that bluntness here because I think it’s the clearest statement I’ve made of what’s actually at stake. Rule Change 1 is the mission statement in its most compressed form: Web 7.0 is profoundly aligned with the oldest promise of the internet — secure, trusted, universal access to information, services, and liquidity, for every human and digital agent on the planet, with no gatekeepers and no overlords. Rule Change 2 is the historical claim I’m willing to stand behind: whoever succeeds in establishing the global Decentralized System Architecture (DSA) standards and reference implementations will occupy the position Microsoft occupied in 1994 relative to the internet — except this time the platform is open, the identity is sovereign, and the shared reserve currency is governed by non-blockchain cryptographic proof rather than by a corporation’s terms of service.
The rest of the rule changes work out the implications of that claim across several fronts at once. As a library operating system, Web 7.0 runs everywhere — Windows, Linux, iOS, Android, FireOS — which means the operating system itself becomes commoditized; the layer that matters moves up the stack. I’ve drawn a direct historical analogy here that I think is worth sitting with: the LOBE is to Web 7.0 what the VBX control was to Visual Basic, and the Trusted Digital Assistant (TDA) is to Web 7.0 what Visual Basic itself was to the Windows ecosystem — meaning the Web 7.0 ecosystem is positioned to supersede the Windows ecosystem the same way Visual Basic once made Windows development accessible to a generation of developers who weren’t systems programmers. Specification inversion completes the picture on the tooling side: a PPML parchment diagram generates the code, not the other way around, and Parchment Programming — which gets its own full treatment later in this book — is not a productivity tool so much as an architectural governance framework for AI-enabled, architecture-to-executable compilation.
On identity specifically: every digital agent is going to need one, and the only real question is who owns it — Microsoft, or the agent itself. The did:drn DID method is built to make agent identity genuinely self-sovereign: no centralized registrars, no Microsoft seat or license costs, no subscriptions, no central authority standing between an agent and its own identifier. An identity, in this architecture, is just a key pair — which is a radical simplification compared to the licensing and account infrastructure most digital identity currently depends on. And lock-in, I’d argue, is a declining asset: the moment a genuine alternative appears that isn’t just marginally better but architecturally different, the switching calculus for an entire industry can change quickly.
The economic stakes get concrete in Rule Change 9, which I think is the most important one in the whole piece. For the roughly two billion adults worldwide who remain unbanked, a Trusted Digital Assistant paired with a DID is functionally a bank account. For institutions that need verifiable settlement without a correspondent-banking relationship, a VTC7 mesh functions as a clearing network. And the Epoch 1 cross-society transfer capability is, in effect, the interbank wire transfer of the agentic internet. Put those together and the TDA becomes the universal application platform for a sovereign internet that has no websites, no cloud services, and no intrinsic dependency on anything except DNS. Web 7.0, in that framing, becomes the decentralized operating system for human and digital-agent participation in the digital economy — and I close that piece with a direct challenge rather than a prediction: can Microsoft summon genuine innovation at this speed? Web 7.0 is one answer to that question. Whether Microsoft takes interest almost doesn’t matter, because adoption of the DSA standards by citizens, governments, and enterprises will force the same outcome regardless of what any one incumbent decides to do.
None of that is abstract futurism — it maps onto specific, ordinary business opportunities that exist right now, and I laid several of them out explicitly. A hospital consortium where each hospital operates its own DID method can issue patient verifiable credentials that any other hospital in the network can verify, with a Merkle log providing an auditable record of credential issuance without ever exposing patient data, and DIDComm handling encrypted referral messages between institutions. A manufacturing supply chain where each tier-one supplier owns a DID method can carry verifiable-credential provenance records signed by the manufacturer’s own DID, with a UTXO-style model tracking component custody the way it would otherwise track currency, and the brand owner playing the role a Federation plays in setting governance rules. A federation of professional bodies — law societies, medical councils, engineering institutes — can each own a DID method and issue member credentials, with cross-body verification riding on the same IDidResolver routing infrastructure the SVRN7 library already needs to exist. Municipal and provincial governments can run a genuine identity federation, where citizens hold identities under their own society’s DID method and cross-society services verify credentials without ever routing through a central identity broker. A neutral platform can host, provision, and govern outsourced digital workforces on behalf of client organizations, ensuring each agent’s behavioral instructions reflect documented, governance-approved mandates rather than internal politics — and I believe the first platform to credibly occupy that space, backed by auditable trust frameworks and cryptographically verifiable policy provenance, will define an entirely new professional-services category from scratch. And as AI pipelines scale into production, the hard problem stops being any single stage of the pipeline and becomes coordination across every partner in an integrated, end-to-end ecosystem — pretraining through training, tuning, deployment, inference, and orchestration, over and over, into monitoring. Web 7.0 is designed to provide the decentralized orchestration backbone for exactly that kind of continuously coordinated, auditable, self-improving, operating-system-agnostic mesh, enforcing security, governance, and responsible-AI practice uniformly at every handoff, and routing real-world feedback back upstream to wherever it’s actually needed for the system to keep improving.
Closing
Read end to end, this is a strange body of work to have produced: mission statements salvaged from a predecessor nonprofit, a definition compressed into a single sentence, an information-scope diagram, a use-case list, an accreditation argument, three successive attempts at a set of founding principles, a roadmap still choosing between candidate designs, a currency proposal, twelve blunt claims about what changes, and six sketched-out businesses. But I think that’s actually the honest shape of what a founding document looks like when it’s written in public, over years, by someone who is simultaneously building the thing and figuring out what it should be. The throughline never moved: identity should belong to the person or agent it describes, not to whichever platform happened to issue the account; trust should be something you can verify cryptographically rather than something you’re asked to take on faith from a gatekeeper; and the infrastructure for both should be open, standards-based, and governed as a public utility rather than owned as a proprietary moat. Everything else — the sixteen principles, the twenty principles, the eight orthogonal principles, the SDO accreditation argument, the Sovrona, the roadmap, the rule changes, the business opportunities — is the working-out of that one commitment under increasingly real-world pressure. The chapters that follow this one get into how it actually gets built: the DIDComm architecture, the DID methods, DIDLibOS, the Trusted Digital Assistant. This chapter was about why it’s worth building at all.
Chapter 7: Decentralized Identifiers and the DIDComm Architecture
Everything I have built under the Web 7.0 and Trusted Digital Web banners rests on two pieces of plumbing: Decentralized Identifiers (DIDs) and DIDComm, the protocol that lets agents holding DIDs talk to each other without a platform in the middle. Get those two things right and almost everything else — verifiable credentials, agentic operating systems, trust circles, digital societies — becomes an exercise in composition. Get them wrong, or leave them informal, and you spend the rest of your career debugging a foundation instead of building on it.
This chapter is my attempt to lay that foundation out in one place, in the order I actually came to understand it. I start with the two analogies I use to explain DIDs and DIDComm to people who have never touched a specification in their life — the retail barcode and the steel shipping container — because both analogies are load-bearing, not decorative; they tell you exactly what problem each technology solves and exactly where the analogy breaks down, which is usually more instructive than where it holds. From there I move into the DIDComm Agent Architecture Reference Model (DIDComm-ARM), the layered model I use to reason about what an agent-based software system actually looks like, and the idea of an always-on trusted personal agent that the ARM is ultimately in service of. Then I get formal: DID method specifications and DID Documents turn out to be textbook abstract data types, DID methods can be composed the way object-oriented languages compose classes and interfaces, and DIDComm capabilities can be described in an interface definition language of their own. With that type system in hand, I walk through how I organize the sprawling landscape of DID methods into clusters, and then present two method families I have specified in detail — DID7, an authority-scoped identifier scheme, and DRN, a bridge between the DID world and the much older world of URNs. I close with Verifiable Trust Circles (VTCs), which is where identity, credentials, and multi-party trust finally come together into a single, reusable pattern.
Barcodes, Shipping Containers, and the Case for a Universal Identifier
I keep coming back to two analogies when I explain why DIDs and DIDComm matter, because both technologies solve a problem that looks like a niche engineering concern until you see it at scale, and then it looks like the single most important infrastructure decision a civilization can make.
The first analogy is the retail barcode. In 1974, a pack of Wrigley’s gum was scanned at a Marsh supermarket in Ohio — the first commercial use of the Universal Product Code. Before that moment, retail ran on manual price tags, clerical data entry, and inventory tracking that was perpetually wrong in one direction or the other: stockouts here, overstock there, no standardization from one retailer or manufacturer to the next. The barcode did not speed up any single step dramatically. What it did was provide a universal, machine-readable identifier that every participant in the supply chain — manufacturer, distributor, retailer, checkout counter — could scan, trust, and act on without having to negotiate a bespoke integration with every other party. That one property, universality plus machine-readability, is what unlocked just-in-time inventory and the global retail expansion that followed.
Digital ecosystems have the equivalent problem, and none of our existing tools solve it. Domain names, IP addresses, UUIDs — all of these are identifiers, but none of them are self-sovereign, portable, and cryptographically verifiable across trust boundaries. A DID is. A Decentralized Identifier is a globally unique identifier that is self-sovereign, verifiable, and resolvable without depending on a centralized registry. The W3C DID Core specification defines a DID as pointing to a DID Document, which carries the public keys, service endpoints, and metadata you need to establish secure communication with whatever the DID identifies — and “whatever” is deliberately broad. A DID subject can be a person, an organization, a physical thing, a digital thing, a logical thing, an abstract entity. Just as a barcode can represent a product, a shipment, or a location, a DID can represent almost anything you need to address.
The mapping between the two is close enough to be genuinely useful as a design tool: the UPC/EAN standard corresponds to the W3C DID Core standard; the barcode scanner corresponds to any DID-resolution-capable system; the traceability a barcode provides from manufacturer to checkout corresponds to the verifiability a DID provides from authentication through data exchange to audit. Where the analogy breaks is instructive, too. Barcodes are managed by centralized registries like GS1; DIDs are inherently decentralized, and anyone can create one. A barcode only encodes an identity — a product number — with no built-in guarantee of authenticity; a DID, resolved to a DID Document, carries cryptographic material that lets you actually verify what you are talking to. And scanning a barcode is trivial compared to resolving a DID, which requires cryptographic operations and, depending on the method, a network lookup. Barcodes reached near-universal adoption decades ago; DIDs are still early. But the strategic shape of the opportunity is the same: DIDs could become the UPC of digital identity, the foundational layer that makes verifiable credentials, smart contracts, and cross-border compliance possible, the same way barcodes became the foundational layer that made modern retail and logistics possible. Retail did not transform gradually as barcodes trickled in — it transformed once barcode adoption crossed a threshold. I expect digital trust to have its own “barcode moment,” and I don’t think it has happened yet.
The second analogy covers the other half of the picture: once you have identified the parties, how do they actually talk? For that I reach for the steel shipping container. Before containerization, cargo moved in an idiosyncratic mess of barrels, sacks, and crates, loaded and unloaded by hand, prone to pilferage and damage, and hopeless at intermodal transport — moving a shipment from ship to rail to truck meant repackaging it at every hop. The container fixed this not by making any individual ship or crane faster, but by decoupling the contents from the infrastructure through a single universal abstraction: a standardized, sealed, stackable steel box that every port, ship, rail line, and truck bed in the world could be built to handle. Marc Levinson’s history of the container puts the resulting cost reduction at something like ninety percent, and the speed and scale of global trade that followed is well documented.
DIDComm — Decentralized Identifier Communication — is that same abstraction applied to digital messages. It is a protocol suite for secure, private, interoperable communication that uses DIDs as endpoints, and it defines how messages get packaged, encrypted, authenticated, and routed between agents. A DIDComm message is a standardized envelope: headers, routing metadata, and a payload, cryptographically sealed with encryption for confidentiality, signatures for authenticity, and checksums for integrity. It is transport-agnostic — the same envelope moves over HTTP, Bluetooth, WebRTC, or email without any change to its contents, the same way a container doesn’t care whether it’s on a ship, a train, or a flatbed truck. It routes through mediators without breaking end-to-end security, the way a container can pass through multiple ports and handlers without anyone needing to open it. And it is payload-agnostic: the message might carry a verifiable credential, an IoT command, or arbitrary application data, just as a container might carry electronics, grain, or furniture.
The mapping again holds up under scrutiny: ISO’s standardized form factor corresponds to DIDComm’s standardized envelope structure; sealed, tamper-resistant containers correspond to encryption and authentication; the intermodal flexibility of container shipping corresponds to DIDComm’s transport agnosticism; and the fact that container standards are managed by ISO rather than controlled by any single nation corresponds to the way DIDComm trust derives from cryptographic keys rather than a central authority. Where the analogy weakens is worth stating plainly, because it tells you what DIDComm still has to solve: containers persist physically across a voyage, while messages vanish after delivery; container labels are visible on the outside even when the contents are sealed, while DIDComm can still leak sender and recipient metadata even when the payload is encrypted; container dimensions have been stable for decades, while DIDComm is still evolving; and containerization achieved near-universal global adoption, while DIDComm remains early. None of that undercuts the core claim. If DIDComm reaches the kind of adoption containers reached, it becomes the logistics backbone of the digital trust economy — the substrate that lets verifiable credentials move across finance, healthcare, supply chains, and governance without every pair of organizations having to build a bespoke integration first.
I want to be explicit about why I lean on both analogies rather than just one. The barcode analogy is about identity — who or what you are addressing. The container analogy is about communication — how a message moves between two identified parties without losing its integrity along the way. DIDs without DIDComm give you a namespace with nothing to send through it. DIDComm without DIDs gives you a transport with no reliable way to know who’s on the other end. You need both, and you need them to compose cleanly, which is exactly what the architecture in the rest of this chapter is designed to guarantee.
The DIDComm Agent Architecture Reference Model
Once you accept that DIDs and DIDComm are the two load-bearing primitives, the next question is architectural: what does a system built out of DIDComm-capable agents actually look like, layer by layer? That’s what the DIDComm Agent Architecture Reference Model — DIDComm-ARM — is for.
I published the first public release of the DIDComm-ARM whitepaper in December 2022, version 0.27, as a design guide for software architects and developers building DIDComm agent-based software systems. A week later I released version 0.40, the second public release, with the abstract and structure fleshed out. The goals of the document have stayed constant across both versions, and I’ll state them the way I originally framed them: better understand the active components of DIDComm agent-based software systems and how they rely on and interact with each other; introduce a graphical modeling language — DIDComm Notation — to help architects visualize new designs; and describe a layered architecture reference model to guide the design of the broadest possible range of DIDComm agent-based software systems.
DIDComm Notation is the visual vocabulary underneath the ARM. It contains elements for modeling conventional REST/HTTP clients, agents, and services; DID-addressable REST/HTTP clients, agents, and services (the same REST world, but now every endpoint is identified by a DID rather than a bare URL); DIDComm clients, agents, and services proper; DIDComm agents that carry verifiable credential message attachments; DIDComm mesh networks; DIDComm user agents; and virtual web drives and keystores. Taken together, this set of modeling elements and the relationships between them is the DIDComm-ARM. It resolves into seven layers, numbered zero through six, each one a strictly richer model than the last:
Layer 0 is the plain REST/HTTP Agent Model — ordinary web services with no DID involvement at all. Layer 1 is the DID Addressable REST/HTTP Agent Model, where the same REST interactions happen but every party is now identified by a DID, giving you portability and verifiability without yet requiring the full DIDComm messaging stack. Layer 2 is the DIDComm Agent Model proper — agents that exchange DIDComm messages directly. Layer 3 adds Verifiable Credential attachments to those DIDComm messages, so an agent can not only talk securely but also carry and present proof. Layer 4 is the DIDComm Agent Mesh Network Model, where agents route messages through each other rather than relying on a single point-to-point channel. Layer 5, documented in an appendix, is the DIDComm User Agent Model — the layer where a human’s actual interface into this system lives. And Layer 6, also an appendix, is the Web 7.0 DIDComm Agent Architecture Model itself, the layer where the whole stack gets assembled into what I call Web 7.0: “a unified software and hardware ecosystem for building resilient, trusted, decentralized systems using decentralized identifiers, DIDComm agents, and verifiable credentials.” I mean that “seventh layer” framing literally — layers zero through six are seven layers, and Web 7.0 sits at the top of that stack rather than being a separate thing bolted onto it.
I wrote the DIDComm-ARM whitepaper for a wide audience on purpose: software architects and application developers first, but also UX specialists, and people working across the broader set of standards efforts touching decentralized identity, verifiable credentials, and secure storage. I was explicit at the time that this was an independent work product — not an official or unofficial output of the W3C, the Decentralized Identity Foundation, the Sovrin Foundation, or the Trust over IP Foundation. That independence matters to how I use the model: it’s a design tool I built because I needed one, not a committee compromise, and the layering is deliberately opinionated about what belongs where.
What the ARM is ultimately building toward is a piece of infrastructure I’ve sketched under a few different names over the years but which I think of most simply as the always-on trusted personal agent. I described one concrete instantiation of it as the Web 7.0 Always-On Personal Data Vault, or AO-PDV. Its primary purpose is to host — possibly multiple — Long-term Memory LOBEs (Loadable Object Brain Extensions) as secondary storage for a person’s or organization’s entire life history, plus their current operating context. The business case is blunt: it’s an upsell of a second device to every smartphone owner on the planet, a companion piece of hardware whose entire job is to be on, continuously, holding your history and your context so that your agents always have something durable to reason from. I’ll return to this idea in more architectural depth later in this book, once the DIDLibOS and Agentic OS material is on the table, but I wanted to plant the flag here: the DIDComm-ARM’s Layer 5 and Layer 6 — the user agent and the Web 7.0 architecture layer — exist to give an always-on personal agent somewhere to live.
DID Method Specifications as a Formal Type System
Everything I’ve described so far treats “a DID” as a black box that resolves to a DID Document. It’s worth stopping to be precise about what a DID method specification and a DID Document actually are, formally, because I think most people underuse this precision and end up treating DID methods as an unstructured grab-bag rather than as instances of a well-understood pattern.
The pattern is the abstract data type, or ADT. An ADT defines a domain — a set of valid values — a set of operations over that domain, and a set of behavioral constraints and invariants, all without specifying how any of it is implemented internally. A stack is push, pop, and peek, plus the invariant that pop returns the most recently pushed value that hasn’t already been popped. A map is put, get, and delete, plus the invariant that get after put returns what you put. The internal representation — array, linked list, hash table — is irrelevant to the definition. An ADT tells you what is valid and what the operations mean, not how they’re built.
A DID method specification is, formally, exactly this. Take did:example, did:key, or did:web. Each one defines a domain — the syntactic structure of valid identifiers under that method, of the form did:<method>:<method-specific-id> — along with the rules for resolving an identifier in that domain and the lifecycle semantics governing how an identifier in that domain comes to exist, gets updated, and gets deactivated. In ADT terms, the method defines the valid elements of its identifier space: Domain = { all valid DIDs conforming to method rules }. And every method defines the same four operations over that domain — create, resolve, update (where supported), and deactivate (where supported) — as behavioral operations whose meaning the specification defines without saying anything about how they’re implemented under the hood, whether that’s a blockchain, a database, or the DNS. That is exactly the abstraction boundary an ADT is supposed to draw. Each method also carries its own invariants: uniqueness guarantees, whether the identifier is mutable or immutable once created, whether resolution is deterministic, and what the authorization rules are for who’s allowed to perform which operation. So the clean statement is: a DID method specification functions as an abstract data type whose elements are DIDs of that method, and whose operations are create, resolve, update, and deactivate under a defined set of invariants — the type, the allowable operations, and the semantic guarantees, with implementation details abstracted away entirely.
Now go one level up. When you resolve a DID, you get back a DID Document, and a DID Document is not just a JSON blob — it is itself a second, structurally distinct ADT. If a DID method defines a collection M = { all valid DIDs under method X }, then every DID in that collection corresponds to a resolvable subject, and the DID Document is the canonical representation of that subject. The method defines the identifier collection; the document defines the abstract representation of each member of that collection. As an ADT in its own right, the DID Document’s domain is the structured state space of a subject — its id, its verificationMethod entries, its authentication methods, its key agreement methods, its service endpoints. Its operations, while not expressed as literal function calls, are defined semantically by the structure of the document: verification of signatures, authentication checks, capability delegation, service endpoint discovery. And its abstraction boundary hides exactly the things you’d expect an ADT to hide — how keys are actually stored, how cryptographic proofs are actually generated, where services are actually hosted — while exposing only what verification methods exist, what services are associated, and what relationships are authorized.
I want to be clear that I don’t think this is a loose metaphor; I think it’s structurally precise, and the table I use to make that case lines the two concepts up directly: type definition maps to method specification on one side and document schema on the other; domain maps to valid DIDs versus valid subject state; operations map to create/resolve/update against verify/authenticate/discover; invariants map to uniqueness and lifecycle rules against key integrity and structural validity; and implementation hiding maps to ledger-or-DNS-or-whatever against key storage and crypto engines. The layering itself is clean and worth stating as three steps: a DID method is an ADT over identifiers; a DID Document is an ADT over resolvable subjects; and applications are supposed to operate only through these two abstractions, never reaching past them into implementation details.
There’s a second-order structural insight buried in this that I think is the more important payoff. A DID method doesn’t just define a type — it defines a type whose elements resolve to another type. In type-theoretic terms, Method : Identifier → Document. The method ADT produces instances of the document ADT. That’s not an incidental detail; it’s analogous to a class factory, or a parameterized type constructor, or a category whose morphisms produce structured objects. The method defines the collection; the document defines the algebra over the elements of that collection. Seeing the architecture this way clarifies why methods have to be formally specified in the first place, why interoperability depends on behavioral invariants rather than shared implementations, why documents have to obey strict structural semantics, and — critically — why implementation diversity across methods doesn’t break correctness. The DID architecture, looked at through this lens, is layered abstraction done properly: a two-level abstraction system, identifier type algebra at level one and subject capability algebra at level two.
Once you have DID methods as a formal type, you immediately want the composition tools that come with any type system, and this is where I’ve been experimenting with what I call the DID Method Open (Multiple) Inheritance Model. The goal is purely pragmatic: I want a developer, on the spot, while writing an application, to be able to model and immediately put to use any DID Ecosystem, DID Namespace, or DID Method they need — and as many of them as they want — and I want that task to be as easy as defining a new database table or a new object class for a data store. The way I’ve prototyped this is with ordinary object-oriented inheritance and interface composition, using C# as the illustration language because its support for default interface implementations makes the pattern easy to show.
The shape of it is a base DIDMethod class implementing an IDIDMethod interface, holding a method name and a reference to an IDIDDocumentRegistry — the thing that actually stores DID Documents keyed by DID. From that base I derive three intermediate classes that correspond to the three broad families of DID method infrastructure I care about: KeyBasedDIDMethod, DNSBasedDIDMethod, and FullyDecentralizedDIDMethod. Each overrides Initialize(), calling up the chain to its base class first and then adding its own behavior — standard single-inheritance composition. The interesting part comes when you need a method that combines a base class’s behavior with several additional, independent capabilities that don’t fit naturally into a single inheritance chain — key rotation, revocation lists, event history logging, and whatever I’m prototyping under the placeholder name IDIDCelStuff. Rather than trying to cram all of that into one linear class hierarchy, I compose it: MegaDIDMethod inherits from FullyDecentralizedDIDMethod and implements IDIDKeyRotation, IDIDRevocationList, IDIDEventHistoryLog, and IDIDCelStuff simultaneously. That’s the “open multiple inheritance” in the name — a single DID method class assembled from one base-class chain plus an open-ended set of capability interfaces, each of which a developer can mix in only when they actually need it. The point isn’t the specific placeholder interfaces; it’s that DID methods, treated as ADTs, compose the same way any other well-typed abstraction composes, using tools every working programmer already has.
The last piece of the formal type system is describing what an agent can actually be asked to do once you can address it with a DID — its capabilities, as opposed to its identity. That’s the job of the DID Interface Definition Language, DIDIDL, which I’ve been drafting as a transport-neutral, message-type-centric capability description format for DIDComm agents. DIDIDL lets an agent publish typed tasks grouped under named process capabilities, describe the request, response, and error schemas for each task, support machine-readable discovery of what it can do, and enable client code generation and validation against those schemas. I borrowed the top-level grouping structure from the APQC Process Classification Framework, a well-established taxonomy of business process categories, because I wanted DIDIDL capabilities to map onto processes people already think in terms of rather than inventing a new taxonomy from scratch.
The DID patterns DIDIDL introduces are layered directly on top of DID7 (which I’ll get to properly in a moment): a Process Capability DID takes the form did7://{authority}/{process-name}_{semdashver}:{capability-name}; a Process Capability Task DID extends that with a task segment, did7://{authority}/{process-name}_{semdashver}:{capability-name}/{task-name}; and a family of discovery DIDs — query-capabilities, disclose-capabilities, query-capability, disclose-capability — let an agent ask another agent what it can do and get a structured answer back. A DIDIDL document itself is a small JSON object: a dididl version number, the agent DID, an array of capabilities, and a schemas dictionary referenced by JSON Pointer from within each task definition. The normative rules keep the structure disciplined: every task must be nested under exactly one capability, capability and task DIDs must be unique within the agent, versioning must be encoded directly in the DID rather than carried out-of-band, the union of all capabilities must form a disjoint partition of the agent’s tasks, and any version change that breaks a schema must bump the major version segment in the DID itself. Discovery follows a simple request/response pattern — an agent sends a query-capabilities message and gets back a disclose-capabilities message enumerating what’s available, with the same pattern recursing down to the level of an individual capability’s tasks. DIDIDL is, in effect, the interface definition language for the operations layer of the DID-method-as-ADT picture I described above: if the method specification tells you what a DID is, DIDIDL tells you what an agent addressed by a DID can be asked to do.
Organizing the DID Method Landscape: Clusters, Candidates, and Governance
None of the formal machinery above answers a much more mundane question: with dozens of DID methods already registered and more arriving constantly, how do you keep the landscape navigable instead of it turning into an unmanaged pile of incompatible identifier schemes? I’ve worked on this from the governance side as much as the technical side, because I think the two problems are actually the same problem.
I start from an analogy I use a lot, and it’s deliberately a little irreverent: chickens, eggs, and roosters as a north star for the global decentralized systems community. If Hens are the Issuers, Roosters the Verifiers, and Eggs are the digital credentials (and, by extension, the DIDs that anchor them), then the classic chicken-and-egg problem in credential adoption resolves once you notice that the entire ecosystem is missing the right catalyst. The prime objective isn’t to recruit more Issuers or more Verifiers first — it’s to increase the demand for and consumption of Eggs by Holders, because demand for eggs is what drives the production of hens, and in turn the demand for roosters. Don’t mess with Mother Nature. I bring this up here because it reframes how I think about DID method proliferation: the goal of organizing DID methods isn’t tidiness for its own sake, it’s removing friction between Holders and the credentials — the DIDs — they actually want to use.
With that objective in mind, I built the Web 7.0 / Trusted Digital Web DID Method Clusters Model, a specification development framework aimed at the DIF did-methods Working Group, whose purpose is to give the sprawling and growing set of DID methods a taxonomy instead of a flat list. The model starts from the W3C DID Core definition — a DID subject can be a person, organization, thing, data model, or abstract entity, and DIDs are decoupled from centralized registries, identity providers, and certificate authorities by design — and then asks: what happens once you take that generality seriously and try to build methods for everything? I call the most ambitious category Universal DID Methods: methods suitable for interacting with what I’ve taken to calling Every Little Thing (#ELT) on the planet, or in the universe, examples being did:object, did:ns, and did:web7. Below that top tier, the Clusters Model Taxonomy organizes methods into a grid of categories — clusters — where a bolded method in a given cell is the model method or exemplar for that cluster, a single method can be the exemplar for more than one cluster, and more than one exemplar per cluster is permitted. It’s explicitly a work in progress rather than a finished taxonomy; a complete version will likely need two or three hierarchical levels, with candidate parent categories along the lines of Live Things, Inanimate Things, Abstract Things, Digital Things, and Business Things.
Taxonomy alone doesn’t manage itself, so I paired the Clusters Model with a governance process borrowed from Sociocracy rather than inventing a new committee structure. In Sociocracy terms, a mini working group is called a circle, and my proposal is that each cluster of DID methods gets managed by its own independent circle, with circle members free to belong to more than one circle, and every circle connected up to a parent circle for administrative purposes — in this case, the DID Method Working Group itself. Sociocracy’s actual selling point for this use case is that it combines consent-based decision-making with a decentralized system of authority, which is exactly the governance shape you want for a taxonomy that’s supposed to stay decentralized in practice and not just in name.
The abstract taxonomy gets a lot more concrete once you ground it in a real person’s actual life, which is the point of a companion piece of work I did on a Toronto songwriter and performer’s economic graph. The clusters post itself sketches what a musician’s economic graph looks like — the network of relationships, rights, credits, and revenue streams a working performer actually has to represent, alongside a similar sketch I did of the LinkedIn economic graph for comparison. The follow-up piece takes that graph and works through DID method candidates against it directly, as a recorded case study rather than a written spec: walking through which methods in the clusters taxonomy would actually fit a real, working musician’s set of identifiers — their performance identity, their session and collaboration credits, their rights and royalty relationships — rather than a hypothetical Every Little Thing. That’s the discipline I try to hold myself to whenever I build an abstraction this general: it has to survive contact with one specific, real person’s messy professional life, not just look elegant on a whiteboard.
DID7: An Authority-Scoped Identifier Scheme
With the type system and the organizing taxonomy in place, I want to walk through the two DID method families I’ve specified in the most depth, starting with DID7.
The problem DID7 solves is that DID Core defines method-based identifiers — did:<method>:<method-specific-id> — but no global namespace layer above the method. Every method is on equal footing with every other method, with no notion of a governance domain, a namespace partition, or a routing layer that sits above individual methods the way the DNS sits above individual hosts. DID7 introduces exactly that: an optional authority component and a two-stage resolution process, while remaining fully compatible with W3C DID Core. I’ve drafted DID7 in more than one editorial style over its life — first as a straightforward IETF Internet-Draft, submitted in the conventional BCP 78/79 format with the standard six-month expiration and IETF Trust copyright boilerplate, and again in two SDO-formatted variants under the Web 7.0 Foundation, one of which deliberately mirrors W3C Recommendation formatting conventions (explicit normative/non-normative separation, ABNF blocks with worked examples, inline cross-references to DID Core) to make it easier for W3C-adjacent reviewers to evaluate. The formatting differs across the three; the technical content is the same evolving specification, and I’ll describe it as one.
The general form is did7:[//<authority-name>/]<method>:<method-specific-id>, with a full ABNF grammar defining the authority, method-name, submethod-name, and method-id productions, and a deliberate exclusion of the colon character from method-id to avoid ambiguity with the method delimiter — colons that need to appear inside a method-specific identifier must be percent-encoded. The authority component is optional. If it’s absent, it defaults to w3.org, and the expansion rule is explicit: did7:<method>:<id> expands to did7://w3.org/<method>:<id>. So DID7 without an authority is not a different thing from DID7 with an authority — it’s DID7 with the authority implicitly set to the default namespace.
An authority itself is a namespace controller: it defines resolver endpoints and governance rules for the set of DID7 identifiers under it. Authorities may define resolver endpoints, governance models, and which methods they support, and they introduce an optional trust boundary for the identifiers in their namespace — but they must not alter DID Document semantics as defined by DID Core. That constraint is the whole point: the authority layer is additive, a routing and governance concern layered on top of DID Core, never a modification of what a DID Document means once you’ve resolved down to it.
Resolution happens in two stages, which is the structural core of the whole scheme. Stage 1, authority resolution, takes the authority component and resolves it to resolver metadata — as a convenience, implementations may do this via a DNS TXT record of the form _did7.<authority-domain> IN TXT “resolver=did7://example.com/resolvers:authority”, validated with DNSSEC where possible, though any verifiable data registry technology is permitted and different authorities are free to use different registries. Stage 2, method resolution, takes the method-specific identifier and resolves it using whatever endpoint Stage 1 discovered, producing a DID Document that must conform to DID Core exactly as if it had been resolved through the ordinary did: scheme.
The compatibility story with DID Core is where I’ve been most careful, because it’s the easiest place to get sloppy and create confusion. Any ordinary W3C DID can be mapped to a DID7 URI: did:<method>:<id> maps to did7://w3.org/<method>:<id>. But that mapping is one-way — there is no general inverse mapping from an arbitrary DID7 URI back to a W3C DID, because DID7 supports authorities other than w3.org that have no DID Core equivalent at all. And critically, implementations must not assume equivalence between a did: identifier and a did7: identifier even when the method and method-specific-id components are byte-for-byte identical. did7://w3.org/example:123 is not the same identifier as did:example:123, full stop, even though one maps onto the other. DID7 is a strict superset namespace: not every valid DID7 identifier is a valid DID, and equivalence must never be assumed by an implementation just because the tail end of the string looks familiar.
The security considerations follow directly from introducing a namespace authority as a new trust surface: the integrity of resolver endpoints must be verified before use, ideally with certificate-based authentication; DNS responses used in authority resolution should be DNSSEC-validated to guard against spoofing; resolver endpoints should use HTTPS, and endpoints on plain HTTP must not be used in production; DID Document cryptographic verification still follows DID Core’s own procedures unchanged; and implementations must not follow a resolver redirect to a third-party domain that isn’t associated with the declared authority. I’ve also proposed registering did7 as a formal URI scheme with IANA under the provisional status, with the scheme semantics stated plainly: resolution proceeds in two stages, authority discovery followed by method-specific resolution, and the resulting resource is a DID Document as defined by DID Core.
A handful of examples make the syntax concrete: did7:example:123 (shorthand, defaults to the w3.org authority), did7://w3.org/example:123 (the same identifier, expanded), did7://dif/web:abc (an identifier under a dif authority using the web method), and did7://acbd1234/custom:xyz_123 (a custom authority and method). On the invalid side, an empty authority and method (did7:///), an empty method and method-id (did7://w3.org/), or a bare scheme with nothing after it (did7:) must all be rejected by conforming implementations. Comparing DID7 to DID Core directly: where DID Core’s namespace is method-only and its resolution is method-specific with no explicit trust layer, DID7’s namespace is authority-plus-method, its resolution is authority-then-method, and it carries an explicit, optional trust layer at the authority level. In one of the working drafts I kept an honest running tally of what’s solid and what’s still open, and I’ll repeat it here because it’s a fair summary of where the specification actually stands: the layering, the ABNF, and the normative language are solid and reviewable; the authority-as-first-class-routing-layer, the two-stage resolution model, and the one-way compatibility rule are coherent but genuinely new; and the canonical authority registry (if any), the resolver discovery standard (DNS versus HTTPS versus something else), and the precise trust semantics of an authority (light governance versus strong governance) remain open design decisions I’m still working through.
DRN: Bridging URNs into the DID Ecosystem
DID7 solves the namespace-and-governance problem for identifiers that are DIDs from birth. DRN — the Decentralized (Universal) Resource Name method — solves a narrower but very practical adjacent problem: what do you do with the enormous installed base of Uniform Resource Names, defined by RFC 8141, that already identify things like ISBNs, UUIDs, IETF RFCs, and EPC-tagged supply chain items, and that predate the DID ecosystem entirely? URNs have no native support for DID resolution, no DID Document retrieval, no cryptographic verification methods, and no service endpoint declaration. Retrofitting the systems that already depend on URNs — bibliographic catalogues, digital libraries, standards registries, supply-chain systems — with an entirely new identifier scheme is impractical. DRN bridges the gap instead of replacing anything.
I’ve drafted DRN in two closely related forms, and I’ll present them as one evolving specification because the underlying design is identical: a deterministic, reversible transformation from any well-formed URN into a DID-compatible identifier. The fuller version registers this as the urn method under the DID7 authority scheme, so a URN like urn:isbn:9780141036144 becomes did7://web7/urn:isbn:9780141036144 — the Decentralized Universal Resource Name. The simpler, standalone version registers it as its own plain DID method, did:drn, so the same source URN becomes did:drn:urn:isbn:9780141036144 — the Decentralized Resource Name, without going through the authority layer at all. Both variants share the same syntax pattern, the same normalization rules, the same resolution modes, and the same design rationale; the difference is purely whether the method rides on top of DID7’s authority-scoped namespace or stands alone as an ordinary DID Core method. I’d treat the choice between them as a deployment decision, not a conceptual one.
The core design goals are stated as three properties, and I hold all three to be non-negotiable for the method to be useful at all. Determinism: a given URN must map to exactly one DRN, with no randomness or external state involved in the transformation, and two URNs that are lexically equivalent under RFC 8141 must produce the same DRN. Reversibility: the original URN must be exactly recoverable from the DRN, with no lossy encoding, hashing, or other irreversible transformation applied along the way. And infrastructure independence: baseline resolution must not require access to any centralized registry, distributed ledger, or network service at all — a conformant resolver has to be able to construct a minimal, valid DID Document entirely from the information already present in the DID string itself.
That last property drives the resolution model, which is structured as three modes of increasing capability and decreasing portability. Mode 1, Stateless Resolution, is required of every conformant resolver: it constructs the DID Document locally from the DID string alone, with zero network dependency, which means it’s fully deterministic and always available regardless of connectivity — you can resolve a DRN offline. The minimum document it produces is small and exact: a @context, an id equal to the DRN itself, and an alsoKnownAs array containing the normalized source URN, which is the property that guarantees a DRN can always be mapped back to the URN infrastructure that predates it. Mode 2, Deterministic Fingerprint, is recommended rather than required: resolvers derive a cryptographic hash of the canonical URN, express it as a did:key identifier, and add it to the document as an equivalentId, giving the DRN a stable cryptographic handle it can use to compose with the rest of the DID ecosystem. Mode 3, Discovery-Enhanced Resolution, is fully optional and is where the method reconnects to network infrastructure when you actually want it — DNS-based lookup, HTTPS well-known endpoints, or content-addressed storage such as IPFS, with discovery rules that are namespace-aware, so a resolver handling urn:isbn: DIDs can apply different heuristics than one handling urn:uuid: DIDs. Anything Mode 3 discovers has to be validated for consistency against the Mode 1 baseline document before it’s returned — the id and alsoKnownAs values must match — precisely so that an enhanced resolution can never silently override what the deterministic baseline already guarantees.
A DID Document produced by a DRN resolver can carry the same optional structure any DID Document can: verificationMethod entries for cryptographic operations tied to the identified resource, and service entries for discovering resources or services associated with the URN, both constrained to conform to DID Core’s own requirements for those properties. What a bare DRN does not do, by design, is assert a controller. In the baseline stateless mode there is no controller property at all, and its absence is meaningful — it signals that control simply hasn’t been established through this mechanism, not that it’s unknown or forbidden. Establishing control is left to layered mechanisms: a verifiable credential binding a controller identity to the URN, a signed DID Document where the signature comes from a verification method under the controller’s authority, or a namespace authority attestation, where whoever registered or maintains the relevant URN namespace formally asserts controller status. Only once one of those mechanisms is applied does the controller property get populated, and it must then reference a resolvable DID.
The same restraint carries through to trust and to CRUD. The method does not inherently provide authenticity guarantees — a Mode 1 document is constructed locally and carries no cryptographic proof of its own origin — so anyone requiring trust assurances has to layer cryptographic proofs, third-party attestations, or namespace authority validation on top of the baseline, and consumers should never infer trustworthiness from the mere presence of a DRN. CRUD support is deliberately asymmetric: Create is implicit, since forming a DRN from a well-formed URN requires no registration step at all; Read is required, at minimum via Mode 1; and Update and Deactivate are simply not supported by the baseline method, full stop — those operations only become possible if an external Mode 3 discovery service independently implements document management, which is outside the scope of the method itself.
I think the honest way to summarize the design is a short list of trade-offs I made on purpose rather than by accident. What’s well-supported: the deterministic mapping aligns cleanly with the general DID design principle that methods should be deterministic wherever possible; reusing alsoKnownAs from DID Core rather than inventing a custom property keeps the method fully conformant while still preserving semantic continuity with the source URN; and the stateless baseline maximizes portability by eliminating any single point of failure that a mandatory registry dependency would otherwise introduce. What I’ve acknowledged as a trade-off: there is no built-in trust layer and no lifecycle operations at the baseline level, and both are pushed intentionally into optional layers — Modes 2 and 3, and the controller model — so that an implementation only takes on the complexity it actually needs.
Two consequences of that trade-off deserve their own attention because they’re the places DRN can go wrong if you deploy it carelessly. On privacy: because the mapping from URN to DRN is deterministic and fully reversible, anyone who observes a DRN can recover the underlying URN immediately, and if that URN encodes personally identifiable information — a personal UUID, a registry identifier tied to a specific individual — the DRN becomes a direct correlation vector, and two parties who independently resolve the same URN will always land on the same DRN, which enables linkage across otherwise unrelated contexts. My recommended mitigations are to use pairwise did:peer identifiers wherever individual interaction tracking is a concern rather than exposing the DRN directly, to avoid forming DRNs from URNs that encode sensitive personal data in public contexts in the first place, and to use verifiable presentations with selective disclosure rather than sharing a DRN outright when verification is what’s actually needed. On security: the baseline method provides no proof-of-control whatsoever — any party can construct a syntactically valid DRN from any well-formed URN without demonstrating any authority over the resource it names, which is an intentional consequence of the zero-infrastructure design, but it does mean a bare DRN can never be used on its own to assert ownership. Mode 3 resolvers face the additional risk of accepting a spoofed or tampered document from a malicious discovery service, which is why I recommend requiring signed metadata on anything obtained via Mode 3 discovery, binding controllers with verifiable credentials rather than trusting document structure alone, requiring TLS 1.2 or higher with certificate transparency on discovery endpoints, and validating every embedded URN against the RFC 8141 grammar before resolution proceeds at all.
If I had to compress DRN into a single sentence, it’s the one I used to close the simplified specification: did:drn transforms a URN into a resolvable, interoperable DID while preserving its original meaning and structure. It’s worth being equally clear about what it isn’t. It is a universal adapter between the URN and DID ecosystems, a semantic identity bridge, and a zero-infrastructure resolution method at baseline. It is not, by itself, a self-sovereign identity system, and it is not a registry-backed authority system — for those, you layer verifiable credentials and namespace attestations on top, exactly as the controller model and the trust section both prescribe.
Verifiable Trust Circles: The Capstone Trust Mechanism
Everything up to this point has been about identifying individual parties and letting them talk to each other securely. The last piece I want to walk through in this chapter is what happens once you need to express something more than a one-to-one relationship — group membership, collective decision-making, and multi-party trust — using the same DID and verifiable credential primitives, without inventing a new credential type for every new kind of group. That’s the problem Verifiable Trust Circles, or VTCs, are built to solve.
The starting observation is that the Trust over IP ecosystem already had two pairwise credential constructs in circulation before VTCs: Personhood Credentials (PHCs), which express proof of personhood, and Verifiable Relationship Credentials (VRCs), which express a bilateral relationship between two parties. Both are useful, and both are also, on inspection, specializations of the exact same underlying pattern — a pattern I call the Partof Architecture Reference Model, or PARM, sometimes just the MemberOf or CitizenOf model. A huge class of real-world relationships — membership, citizenship, being part of something, employment, participation, even casting a vote — reduce to the identical logical shape: a verifiable credential whose subject identifies the group or decision entity (the circle itself), and whose proof array contains a contribution from a Notary plus one contribution from every member who has accepted membership. MemberOf a working group, PartOf a study group, CitizenOf a digital nation state, EmployeeOf a DID-identified company, ParticipantOf a scheduled meeting, VoterFor a candidate — every one of these collapses to the same credential structure once you strip away the surface vocabulary. PHCs and VRCs are just the N=1 and N=2 degenerate cases of that one general pattern.
The mechanism that makes a single, general N-party construct possible without inventing new cryptography is the VC Proof Set — a normative feature of the W3C Verifiable Credential Data Integrity specification, explicitly designed for situations where the same secured document needs to be signed by multiple entities. A VTC is nothing more than a valid W3C Verifiable Credential that deliberately uses the proof property as an array rather than a single object, with one proof contribution per participating member. The issuer identifies the Notary — a trusted third party, trusted by every party in the circle, who creates the credential shell and contributes the first proof. The credentialSubject (or, where selective disclosure matters, a confidentialSubject) carries a from property identifying the Initiator, a to array identifying the Responders, and an optional metadata object for whatever else the relationship needs to carry, while credentialSubject.id identifies the circle itself — the group or decision entity — as a DID. Proofs accumulate into that array conventionally in the order Notary, then Initiator, then Responders, though Proof Sets are formally unordered by definition; the convention is purely for auditability. A minimal bilateral VTC between two parties is structurally identical to a VRC. A VTC with no upper bound on the to array — Alice through Zelda, in the illustrative case I use — is a working group roster. A VTC where to contains only the Initiator’s own DID degenerates into a PHC-equivalent self-attestation. And a voting scenario is handled by minting one VTC per candidate and letting each voter cast a vote simply by contributing their own proof to the VTC of the candidate they support — the vote count for a candidate is nothing more than the number of valid member proofs present in that candidate’s Proof Set, which gives you enormous flexibility in counting policy (simple majority, ranked choice, threshold) for free, because the tallying logic lives entirely outside the credential format.
The lifecycle of a VTC is worth being precise about because it’s what makes partial, in-progress circles meaningful rather than invalid. Phase 0 is the Null VTC: the Notary creates the credential shell, with the to array either empty or pre-populated, and contributes the initial proof; no member relationship is yet verified, and the count of verified members, t, is zero. Phases 1 through t are Progressive Endorsement: each Responder, in whatever order they choose, reviews the credential and, if they consent, appends their own proof to the existing Proof Set using the add-proof-set-chain algorithm defined in the VC Data Integrity specification — critically, without modifying any proof already present. At any point during this phase the VTC is valid for exactly the t members who have signed so far; non-signing members are proposed but not yet bound. Phase N is the Complete VTC, reached once every Responder listed in to has contributed a proof. A verifier examining a VTC at any point in this lifecycle must check which proofs are actually present before asserting anything about full circle membership — a partial VTC is a legitimate credential representing the subset of relationships established so far, not a broken or incomplete one.
The design principles I held myself to while specifying VTCs are worth stating because they explain some of the choices above. As simple as possible but no simpler: VTCs introduce no new cryptographic primitives and no new credential types — the only structural move is the deliberate use of the existing proof array as a genuine Proof Set. First principles thinking: rather than maintaining separate credential types for PHCs, VRCs, and every new relationship shape that comes along, I derived one universal type that covers all of them by varying the cardinality of to and the composition of the Proof Set. Privacy by design: VTC credential subjects should use confidentialSubject semantics wherever selective disclosure matters, so a member can prove their own membership to a verifier without revealing the full membership list, and Zero-Knowledge Proof integration into individual proof entries is explicitly supported and encouraged rather than treated as an afterthought. Composability: VTCs compose cleanly at each layer of the Self-Sovereign Control 7.0 Metamodel’s three controller layers — a VTC anchored at the Beneficial Controller layer expresses human-level trust relationships, one at the Intermediate Agent layer expresses agent-level relationships, and one at the Technical Controller layer expresses device- or key-level relationships, all using the identical pattern. And cross-network trust: PARM and VTCs are network-agnostic by construction, so the same pattern supports trust relationships that span across and between otherwise independent networks and ecosystems.
The use cases I’ve worked through span a genuinely wide range for something built on such a small structural addition: a bilateral trust relationship that’s the exact functional equivalent of a VRC; a self-signed personhood credential that’s the exact functional equivalent of a PHC; a working group or task force roster that becomes cryptographically verifiable simply because members join by contributing proofs rather than being added to a spreadsheet; a VC-based meeting request where attendees RSVP by contributing their proof, making attendance itself verifiable from the resulting Proof Set; voting-based decision-making, as described above; a verifiable decentralized registry, where append operations to a distributed registry are authorized through a VTC whose members are the registry’s trustees; and, at the largest scale, a digital society or digital nation state, where the citizenry itself is defined by a VTC and subsidiary governance operations — electing trustees, passing resolutions — are carried out through further, subordinate voting VTCs nested underneath it. That last case is where I think the pattern earns its keep most clearly: a single, small, well-specified credential mechanism scales all the way from two friends attesting to a relationship up to the governance structure of an entire digital society, without changing shape at any point along the way.
The privacy and security considerations that come with multi-party proof sets deserve to be taken as seriously as the data model itself, and a few of them are specific to VTCs rather than inherited generically from verifiable credentials. The Notary occupies a genuinely privileged position — it issues the shell and contributes the first proof — so a verifier must independently confirm that the Notary is actually trusted by every relevant party rather than assuming trust from the credential’s structure alone; I recommend the Notary be a well-known, community-governed DID with transparent governance rather than an opaque service. Voting VTCs carry their own integrity requirements on top of the general model: eligibility, so only eligible voters can contribute a proof; anonymity, so voter DIDs should be anonymized or pseudonymized where the election calls for it; non-repudiation, since every proof is cryptographically bound to the voter’s own key; and single-vote enforcement, so the to array or the Notary’s own policy has to prevent the same voter DID from contributing a duplicate proof. And there’s a subtler consideration that came up specifically around internal VTCs — cases where multiple agents controlled by a single First Person are contributing proofs to a shared circle — which I think of as a privacy budget and reconstruction ceiling: the combined disclosure across every proof entry contributed by that person’s various agents must not let an observer reconstruct the First Person’s identity with a probability above the threshold their applicable trust framework allows. It’s a reminder that privacy in a multi-party proof set isn’t just about any single proof; it’s about what the set of proofs, taken together, reveals.
Closing
Laid end to end, the arc of this chapter is really one argument told in five registers. DIDs give you a universal, self-sovereign way to name anything — the barcode argument. DIDComm gives you a universal, secure way to move information between named parties — the shipping container argument. The DIDComm-ARM gives you the layered architecture for assembling those two primitives into real agent-based systems, in service of an always-on personal agent that can actually hold someone’s history and context. Treating DID methods and DID Documents as abstract data types, composing methods the way object-oriented languages compose classes and interfaces, and describing agent capabilities in an interface definition language gives you the formal discipline to keep that architecture from collapsing into ad hoc code as it grows — and organizing the resulting landscape of methods into clusters, grounded against a real person’s actual economic graph, keeps the whole exercise honest. DID7 and DRN show two concrete, worked examples of what a well-specified method family looks like once you take that discipline seriously — one adding a namespace and governance layer above DID Core, the other bridging four decades of existing URN infrastructure into the DID world without breaking anything that already depends on it. And Verifiable Trust Circles show what you get once identity and secure communication are solid enough to build on: a single, minimal credential pattern that scales from a personhood attestation for one person, to a bilateral relationship between two, to the governance of an entire digital society, without ever changing its fundamental shape.
None of this is finished. DID7’s authority registry and resolver discovery standard are still open questions; DRN’s privacy mitigations are recommendations, not enforced guarantees; VTCs depend on Notaries behaving well and verifiers checking Proof Sets carefully rather than trusting credentials on sight. But I think the foundation is sound, in the specific sense that matters to me as an architect: every piece composes cleanly with every other piece, nothing here requires you to trust a platform, and the whole stack — from a barcode-simple identifier up through a societal-scale trust circle — is built out of primitives precise enough to specify formally and simple enough that a working developer can pick up exactly the piece they need and leave the rest. That is the standard I hold this entire body of work to, and it’s the standard the rest of Web 7.0, in the chapters that follow, is built on top of.
Chapter 8: DIDLibOS, AgenticOS, and the Trusted Digital Assistant
The previous two chapters laid out the vision and the wiring: what Web 7.0 is for, and how Decentralized Identifiers and DIDComm messages move trust between parties who have never met and may never need to. This chapter is about what happens when you stop treating that wiring as a protocol and start treating it as an operating system. Once you commit to the idea that everything — every message, every credential, every function call, every unit of persistent state — is addressed by a DID, you are no longer designing a messaging standard. You are designing a kernel. That is the turn this chapter documents: from Web 7.0 as an identity and trust layer to Web 7.0 as Pando, DIDLibOS, and AgenticOS — a decentralized, DID-native, DIDComm-native operating environment for building Trusted Digital Assistants, and, through them, entire decentralized societies.
I want to walk through this in the order I actually built it, which is also the order that makes the most sense to explain it in. First comes the conceptual foundation: what a person is, what a digital persona is, what a digital agent is, and what it means for a flesh-and-blood human being to remain in Self-Sovereign Control (SSC) of all three. Then comes the operating system itself — Pando, the Agent Architecture Reference Model (AARM), and DIDLibOS as a polyglot host running on PowerShell runspaces. Then comes the system architecture that turns the OS into a running, deployable thing: the Decentralized System Architecture (DSA) and the detailed design of its central citizen-facing component, the Trusted Digital Assistant (TDA). And finally I want to close on a small, deceptively important piece of naming discipline — the distinction between a locator DID and an identity DID — because without that distinction, none of the rest of it actually works.
Persons, Personas, Agents, and Self-Sovereign Control
Everything in this architecture rests on getting three things right and keeping them separate: the flesh-and-blood person, the digital persona, and the digital agent.
The flesh-and-blood person is the easy one — it’s you, sitting at a keyboard, or walking around Bindloss, Alberta, with a phone in your pocket. The digital persona is a projection of that person into digital space: a bundle of claims, an identifier, a name people (or systems) recognize you by. And the digital agent is the software — the Trusted Digital Assistant — that acts on behalf of a persona, executing tasks, sending and receiving DIDComm messages, holding keys, and exercising authority that the person has delegated to it. The mistake almost everyone makes when they first encounter self-sovereign identity is collapsing all three into one thing: “my identity.” They’re not one thing. They’re three, and the entire architecture I’m about to describe is organized around keeping them distinct while making the relationships between them cryptographically verifiable.
A single person can have multiple personas — that’s not a bug, it’s the whole point. In one of the AARM’s non-normative appendices I sketch this out with Alice and Bob. Alice has two digital personifications: Alice Smith and Alice Athlete. Each has its own digital ID, its own set of claims, and — critically — its own Trusted Digital Assistant. Alice Smith’s TDA is not the same running agent as Alice Athlete’s TDA, even though both are, at the root, controlled by the same flesh-and-blood Alice. Bob goes further: he has at least four digital personifications — Bob Aggie, Bob Nova, Bob Sovronia, and Bob Developer — each potentially a member of a different Web 7.0 network, each with its own trust relationships expressed through Verifiable Trust Circles and Verifiable Trust Credentials. This is the SSI 7.0 Identity Framework in miniature: a root person surrounded by a constellation of personas, each with its own identity, its own identifier (which may be a plain name like ALICE SMITH or ALICE DIGI, or may be a DID, or both), and its own set of projected claims.
I call the discipline that keeps this constellation coherent Self-Sovereign Control, or SSC, and I’ve come to believe SSC is the real successor to Self-Sovereign Identity (SSI). SSI, as a term, has mostly stayed a slogan — a decade of conferences and manifestos without a concrete architecture that ordinary systems architects could actually build against. SSC is different because it starts from a working definition of identity that a systems architect can use directly. It comes from Tim Bouma’s framing, in his essay “Things in Control,” and it’s the best one-line definition of identity I’ve come across: identity, properly understood, is a capability surface — the total set of Things in Control that a person can activate. Not a set of attributes. Not a credential wallet. A capability surface. What can this entity actually do, and what is it in control of?
That reframing is what the SSC 7.0 Metamodel — which I’ve also taken to calling, only half-jokingly, the Grand Scheme of Things (GST) — is built to formalize. The metamodel organizes control into layers: a Beneficial Controller layer, an Intermediate Controller layer, and a Technical Controller layer. The Beneficial Controller is the ultimate human interest being served — Alice, the actual person, the beneficiary in the fiduciary sense. The Technical Controller is the machinery that actually executes cryptographic operations — keys, signing routines, the agent runtime. The Intermediate Controller sits between them, and this is usually where the interesting governance questions live: an organization, a guardian, a trustee, a delegated authority that has been granted specific capabilities over specific things without owning the whole capability surface. Every layer of the metamodel can host a Verifiable Trust Circle (VTC).
I want to be precise about what a VTC is, because the term gets thrown around loosely elsewhere. A Verifiable Trust Circle is not a straight-line edge between two parties the way a typical “trust relationship” diagram would show it — it’s a circle relationship. A VTC can have one member, two members, three, or more, and it’s built on multi-proof verifiable credentials — what used to be called, in earlier working-group language, UMCs. Multiple VTCs, some of them overlapping and some of them entirely disjoint, together form a Verifiable Trust Graph (VTG). VTCs aren’t just an abstract trust-modeling convenience; I use them to represent single-party, two-party, or multi-party membership and citizenship relationships, and to implement higher-level processes: working groups, study groups, task forces, digital nation-state processes, multi-person meeting requests, trustee and notary elections, voting-based decision-making, review-and-approval routing, contract execution, counter-signing, polls, and petitions. Chain several VTCs together in sequence — a governance process where approval has to pass through one circle, then another, then another — and you get what I call VTC ChainMail: a linked structure of trust circles that models a multi-stage approval or accountability process the way chainmail links individual rings into a single protective fabric.
Note the fiduciary language creeping in here — beneficiary, trustee, controller — and it’s deliberate, not decorative. In the AARM I draw this out explicitly: a Beneficiary (Alice, the person) has a trusts and fiduciary duty relationship with her Beneficiary Agent, which acts as her trustee. The same pairwise structure — one party as beneficiary, the other as trustee — recurs at every level of the system: agent to agent, persona to agent, organization to agent. Trust in this architecture isn’t a vague social sentiment; it’s a legal-adjacent relationship with duties attached, and the metamodel is built to make those duties inspectable.
This is also the frame I use for what I’ve called, somewhat provocatively at a mock-Davos presentation, Identic AI: artificial intelligence powered by Web 7.0 AgenticOS, where the “identic” part is the point — the AI is not a disembodied model answering questions from nowhere, it is identified, tied to a DID, operating within a capability surface that a beneficiary has actually granted it, inside a trust graph that can be audited after the fact. Don Tapscott’s recent argument for what he calls “Universal Basic AI” gets at the same instinct from the policy side: AI needs to be decentralized in technology, ownership, and governance, not concentrated on monolithic servers controlled by a handful of firms. Tapscott is right about the diagnosis. Identic AI, running on AgenticOS, with every actor a DID holder and every capability grant a verifiable credential inside a VTC, is my answer to the prescription: a decentralized platform for our digital selves, and for the digital agents that act as our hands.
Pando, the AARM, and DIDLibOS: Building the Operating System
Everything above is conceptual scaffolding. None of it means anything until it’s implemented in running software, and that’s where Web 7.0 Pando comes in.
Pando is the name I’ve given to the macromodular, neuromorphic agent platform that coordinates and executes complex systems of work across the Web 7.0 ecosystem — secure, trusted, open, and resilient. Pando’s development project carries the internal codename “Shorthorn,” which is a deliberate parody of Microsoft’s Windows “Longhorn” — the WinFS project I had some design-preview, consulting, and PM-training exposure to back around 2001–2002 (a story I tell in more detail elsewhere in this collection). The joke has a point behind it: what makes Shorthorn cattle a genuinely good breed is that they’re efficient at turning grass into meat, they’re excellent mothers who raise strong offspring, and their genetics blend well with other breeds to produce strong hybrids. Substitute “resources” for grass, “decentralized societies” for offspring, and “other systems” for other breeds, and you have a fair description of what I want Pando to be. Pando itself is developed and stewarded by the Web 7.0 Foundation, a federally incorporated Canadian non-profit based in Alberta, chartered to develop, support, promote, protect, and curate the whole Web 7.0 ecosystem — software, standards, and specifications together.
The lineage of this work goes back further than people expect — roughly thirty years, to before 1998 and the release of Alias Upfront for Windows, a product Bill Gates once called the most outstanding graphics product for Microsoft Windows 3.0. Out of that project came the AUSOM Application Design Framework — “A User State of Mind” — an approach to designing client-side applications around user scenarios, task analysis, state-transition diagrams, and modeless interaction. AUSOM’s central insight was that a highly modeless interface still has to accommodate genuinely modal tasks (letting a user reshape a polygon mid-sketch, for instance) without forcing the whole application into a rigid mode stack. That same instinct — build the smallest possible amount of rigid structure, and let capability be composed dynamically on top of it — runs straight through to Pando’s design forty years later. Charles Simonyi’s advice from my Microsoft years, echoing Einstein — “no problem can be solved from the same level of consciousness that created it” — is part of why I eventually left the company in 2001, and it’s part of why Pando is not an incremental extension of any existing OS architecture. It’s a rebuild from first principles, aimed specifically at software for building decentralized societies, not just decentralized apps.
The Agent Architecture Reference Model
The technical heart of Pando is the Agent Architecture Reference Model, or AARM — sometimes written NAARM to emphasize its neuromorphic framing (Neuromorphic Agent Architecture Reference Model). The brain metaphor isn’t decoration; it’s load-bearing. A Web 7.0 agent is modeled as a Frontal LOBE plus a Neural Messaging pathway. The agent communicates with the outside world — other Web 7.0 agents — through three interfaces: Outbound (“Talking”), Seeing, and Inbound (“Listening”). Agents remain dormant until a message arrives addressed to them, and return to dormancy once the queue is empty; processing can be paused without losing anything in flight, because incoming messages are received, queued, and persisted to long-term memory the moment they arrive, and can be resumed at any time. DIDComm over HTTP is the default secure transport, and DIDs define the identity layer that runs underneath the whole messaging superstack.
The unit of extensibility is the LOBE — Loadable Object Brain Extension — a macromodular, neuromorphic intelligence framework that lets a system grow, adapt, and evolve by making it trivially easy to add new capability at any time. Each LOBE is a self-contained cognitive module, dynamically loadable, that extends the Frontal LOBE’s functionality for perception, reasoning, coordination, or control. String enough LOBEs together and you get an ecosystem of interoperable intelligence rather than a monolith — developers building distributed, updatable, extensible minds instead of shipping a fixed feature set. Above the level of an individual agent sits the Neuroplex: a dynamically composed, decentralized, message-driven cognitive solution spanning one or more agents, each with its own configurable set of LOBEs. A Neuroplex is emphatically not a traditional client-server application; it’s an emergent, collaborative execution construct assembled from independent, socially developed cognitive components connected by messages, and its execution is kicked off with what I call a NeuroToken.
One of the more useful moves in the AARM is showing how Coordination and Execution LOBEs can be deployed at different granularities without changing the underlying model. You can horizontally unbundle them — assign every LOBE to its own distinct Frontal LOBE, an extreme deployment pattern useful mainly for illustrating the range of what’s possible — or horizontally rebundle them into the more common, practical pattern where a small number of Frontal LOBEs within a Neural Cluster each host a reasonable collection of Coordination and Execution LOBEs together. At the minimal end of that spectrum sits the simplest possible useful deployment: a single agent hosting one Trusted Digital Assistant LOBE, which is exactly the TDA I’ll return to later in this chapter — and there’s a variant of that minimal deployment, the MCP-enabled TDA, that exposes an MCP interface so the assistant can be driven by, or drive, external tool-calling AI systems.
Zoom out one more level and you get Neural Clusters: groups of agents where all messaging external to the cluster passes exclusively through a single Beneficial Agent, while any additional messaging inside the cluster boundary stays confined to the Beneficial, Coordination, and Execution LOBEs deployed there. This pattern maps cleanly onto real multi-agent use cases already appearing in industry — I cross-referenced it directly against PwC’s multi-agent customer support architecture, where their “master agent” is my Beneficial Agent, their “orchestrator agent” is my Coordination Agent, and their “micro-agents” are my Execution Agent LOBEs. The terminology differs; the shape of the solution doesn’t.
DIDComm 7.0 is the messaging fabric that ties all of this together, and I’ve found the cleanest way to explain it is by analogy to two things most engineers already understand: Unix pipes and PowerShell pipelines. A DIDComm Message can be piped from one agent’s Outbound Interface directly to another agent’s Inbound Interface, composing secure, trusted agent-to-agent pipelines the way Unix pipes compose text streams, or the way PowerShell pipelines compose a stream of .NET objects — except DIDComm 7.0 does it better, because PowerShell famously never clones, serializes, or duplicates .NET objects moving through a pipeline (with a few special-case exceptions); it passes a single instance reference from one cmdlet to the next. DIDComm 7.0 does the same thing for DIDComm Messages: a message (DIDMessage) can be passed by reference from LOBE to LOBE, in-memory, entirely without serialization, deserialization, or physical transport over HTTP or any other wire protocol. The parallel is precise enough that I lay it out as a direct terminology crosswalk: tdwagent.exe is to powershell.exe as a LOBE (Agenlet) is to a Cmdlet, as a Verifiable Credential is to a .NET Object, as a DIDMessage (JWT, passed by reference) is to a PSObject (passed by reference), and as a Web 7.0 Verifiable Trust Circle is to a PowerShell Pipeline. Where PowerShell routes serially through a fixed pipeline, DIDComm 7.0 routes across an arbitrary graph, keyed on Receiver DID, Sender DID, and message type. One reviewer of an early draft called the by-reference optimization “quite clever” — it’s the single design decision in the messaging model I’m proudest of, because it means trust and performance stop being in tension with each other.
Every element in the AARM that has, or will need, an identity — an agent, a persona, a LOBE, a Neural Cluster, a message type — is enumerated in the Neuromorphic Agent Identity Model (NAIM), a companion chart whose entire purpose is making sure nothing in the architecture is left without a DID and a DID Document to anchor it. That completeness discipline is what makes the identity/locator distinction I’ll cover at the end of this chapter possible to apply consistently: you can’t classify DID fields correctly if you haven’t first enumerated everything in the system that’s entitled to have one.
The Trust Graph and the Pure Peer Model
Sitting alongside the AARM is the AgenticOS Trust Graph, built on what I call the Pure Peer Model. The name says most of what matters: there is no privileged hub, no central authority node that every trust relationship has to route through. Every agent, every persona, every TDA is a peer in the graph, and trust relationships — expressed as the Verifiable Trust Circles described above — are formed directly between the parties that need them, not brokered through some intermediary that has to be trusted by construction. This is the same pure peer discipline that shows up again later in the DSA’s VTC7 mesh: every Citizen TDA that participates runs the same software at the same architectural level, and cross-party communication flows through each peer’s own DIDComm/HTTP Listener rather than through a shared database or a central broker. The Trust Graph is where that peer-symmetry gets modeled explicitly as a graph structure, independent of any specific deployment.
DIDLibOS as a Polyglot Host
With the AARM as the conceptual reference model, DIDLibOS is what actually runs. The clearest single-sentence description I’ve landed on is this: Web 7.0 DIDLibOS is a decentralized, DID-native polyglot host platform. A polyglot host is a software environment that can execute or embed multiple programming languages within the same process or platform — instead of being tied to one language runtime, the host provides the infrastructure (memory management, object sharing, APIs, execution control) that lets different languages run side-by-side and interact. PowerShell is the paradigm case I keep coming back to, because PowerShell itself already acts as a host orchestrating multiple runtimes underneath it: .NET languages like C# and F#, JavaScript through embedded engines, Python and other external runtimes, and legacy scripting through its own compatibility layers. .NET Interactive is another good real-world example — a single notebook supporting C#, F#, PowerShell, JavaScript, and SQL side by side; Jupyter notebooks do the analogous thing through kernels.
There are, broadly, three architectural patterns a polyglot host can follow: languages can run as embedded runtimes inside the host process itself, sharing an object model directly; the host can launch interpreters as external runtimes in subprocesses (which is largely how PowerShell handles Python or Node); or the host can expose a plugin scripting engine interface that each language implements against, the way Windows Script Host let VBScript, JScript, and PerlScript all plug into a common execution contract. DIDLibOS borrows something from each of these patterns, but the defining move — the thing that makes it DID-native rather than merely polyglot — is what happens when you decide that every runtime value passed between execution steps is going to be a DID rather than a language-native object.
I first worked through the implications of that decision out loud, at length, in a DIDComm user group presentation, and it’s worth walking through the reasoning the way I laid it out there, because the logic builds in a specific order. Start with the concept of a library operating system. At the bottom you have the traditional host or operating system services you’d expect from any OS. A library OS sits on top of that and provides a system of libraries that expose an ecosystem- or framework-specific set of interfaces — and critically, applications never reach down past the library layer to call the raw OS interfaces directly. Everything goes application layer → developer abstraction → library layer → host abstraction layer. This isn’t a new idea — it was pioneered in the 1990s, and there’s ongoing research into making Windows itself more library-OS-like, shrinking the kernel and pushing functionality into user-space libraries, which is really a lightweight alternative to full virtualization. The terminology I use for the boundary applications talk to is the north interface (a term that goes back to an OS research project from around 1990); the library OS calls down through a south interface to the underlying host; and optionally there are east and west interfaces for things that don’t cleanly fit the north-south flow — in DIDLibOS’s case, the west interface hosts the libraries for constructing DIDComm message payloads, trust relationships, and the cryptographic trust primitives (hashing, signing, verification, encryption, decryption) that sit under Web 7.0 Foundation governance.
What sits in the library layer, just above the south interface, is a deliberately generic list until you fill it in: identity and messaging protocols, long-term (persistent) memory, a fast cache for quick access to frequently used objects, an agent framework, and a call interface down through the south interface to host resources. Fill in the Web 7.0 specifics and you get: identity is DIDs, documents, and a DID registry; messaging is DIDComm messages; long-term memory is, remarkably, also DIDComm messages, used as the serialization format for persistence; the fast cache is DIDComm-message-based too; and the switchboard is the component that listens on the inbound interface, inspects each message’s type and thread ID, and decides which of the modules above it a message should be routed to.
The phrase I keep coming back to is DID-exclusive: everything is a DID. That’s not a slogan, it’s a design constraint I apply relentlessly, and it has real costs I don’t pretend away. Calling a function or method inside the operating system means constructing, and often verifying and decrypting, a DIDComm message to do it — including for internal, in-process operations that a conventional OS would handle as a plain function call. I’ve had people push back on that as needlessly expensive, and my answer is: yes, it is expensive, precisely because it’s used everywhere — for persistence, for the fast cache, for routing, for passing parameters. But if that turns out to be the slowest part of the system, it will also be the part everyone is motivated to optimize, and I’m not worried about a well-understood performance bottleneck going unsolved. What I am not willing to trade away is the uniformity: a system where identity is the substrate for literally everything, rather than identity being bolted onto an otherwise conventional object model as an afterthought.
That DID-exclusive commitment is also what motivated my proposal for uniform DIDComm message types, which is really a naming scheme borrowed from three places at once: the DID specification’s own authority/method structure (which I deliberately invert — I want the second component of a DID to function as a method subordinate to a first-component authority, not the reverse, which is how the spec actually defines it today); the APQC Process Classification Framework’s process/capability/task hierarchy; and PowerShell’s verb-noun naming convention for cmdlets. Put together, a fully worked message type looks like did:web7:onboarding_1-0/enrollment_1-0/verifyEmail — an authority (web7), a process with a semantic version (onboarding-1-0), a capability (enrollment-1-0), and a task (verifyEmail) — using dashes instead of dots for version numbers so the whole thing parses cleanly. You can also address at the capability level to ask “what tasks do you support,” or at the process level to ask “what capabilities do you support,” which turns a digital agent into something you can introspect the way you’d introspect an assembly’s type metadata. Naming a module after the process-plus-capability concatenation means an agent’s first move on receiving a message is simply checking whether that module is already loaded — and if it isn’t, fetching and importing it on demand. This is, deliberately, a rejection of DIDComm’s existing wire compatibility in favor of internal consistency; I’ve called the Web 7.0 variant DIDComm++ half-jokingly, because it is inspired by the spec but not wire-compatible with it, and interoperability with the broader DIDComm ecosystem has, so far, been a lower priority than getting the architecture internally coherent. I don’t take that trade-off lightly, and it’s the single thing about DIDLibOS’s design that draws the most pushback from people already invested in the existing DIDComm spec — reasonably so, since the spec itself is inconsistently DID-centric to begin with (I count, at one point, well over a hundred references to http/didcomm.org in the spec, most of them for retrieving schema, against essentially two working DID-based examples, one of which doesn’t even conform to its own grammar).
The execution substrate underneath all of this is PowerShell, and the choice is not incidental. PowerShell is cross-platform, open source, and — more importantly for this purpose — it already behaves like an operating system in miniature. You can create runspace pools, where each runspace is an isolated execution area; you can import modules into a runspace, where a module is a set of commandlets (cmdlets); and a runspace can host an entire workflow — a purchasing process, a systems-administration process, a request-for-quotation process — as either a script or a compiled program. That’s the heart of a digital agent in this architecture: a Unix shell (bash, ksh, whatever you’re used to) with a DIDComm endpoint bolted onto the front of it, running on a rich, multi-platform, multi-OS execution environment that already existed and already worked. The LOBEs I described earlier in the AARM are, concretely, PowerShell modules, dynamically loaded whenever a DIDComm message arrives that names a capability implemented by that module — which is exactly why I insisted on the naming scheme lining process, capability, and module name up one-to-one, with no lookup tables or translation layers required in between.
There’s a networking layer underneath all of this too, which I’ve sketched as an eventual replacement — or, more precisely, a DID-native peer — of the raw socket layer applications normally sit on: an “interdidnet,” built by taking the open-source guts of the ZeroTier virtual networking project (which already assigns every device a 64-bit device ID with its own public/private key pair for encrypting packets on its virtual network) and putting DIDComm addresses on top of the physical IP layer instead of the virtual-IP-on-physical-IP scheme ZeroTier uses today. The appeal isn’t abstract: it turns DIDs into first-class network citizens, so that communicating with another user or device is a matter of sending a message to their DID rather than resolving a hostname first and trusting the resolution chain that gets you there. I don’t want to overstate where that stands — it’s a direction of travel, not a shipped subsystem — but it’s the piece that, if it lands, finally lets DIDComm run natively end to end instead of tunneling through HTTP.
The DIDLibOS Whitepaper: Identity-Addressed Execution
The user-group conversation above is where the ideas got argued out loud; the DIDLibOS Whitepaper is where I wrote them down as a formal specification, and the two documents are best read as complementary passes over the same system rather than as two separate descriptions of two separate things. Where the transcript explains the why through analogy and live back-and-forth, the whitepaper states the what as a set of design principles and layers, and it’s worth walking through those directly because they resolve some of the informal language above into something closer to an actual runtime contract.
The whitepaper’s governing idea is captured in its subtitle: identity-addressed execution, event-sourced memory, and runspace-orchestrated agent computing. Concretely: DIDLibOS defines an execution architecture in which all computation happens over DIDComm messages persisted in a single LiteDB instance per agent. Instead of passing in-memory objects between computational steps — the thing every conventional scripting and automation environment does, and the thing that breaks down under distributed execution, concurrency, and long-term persistence — the system passes DID strings that resolve to immutable message state stored in a persistent memory kernel. Computation becomes a function over persistent state, not over transient memory. That’s the whole idea, and everything else in the whitepaper is working out its consequences.
The system decomposes into four layers: an Execution Layer of PowerShell runspaces running cmdlets; an Identity Layer of DIDComm message identifiers; a Memory Layer, the per-agent LiteDB persistent store; and an Acceleration Layer, a transparent in-memory cache managed by LiteDB that has no semantic visibility into execution — it only ever speeds up DID resolution, never changes what gets resolved. Seven core design principles hold the whole thing together, and I’d single out three as doing most of the work: DIDs are the only runtime values passed between cmdlets (not references to objects, not serialized payloads — the identifier itself, resolved on demand); no shared in-memory objects exist across runspaces, which is what makes runspace isolation actually meaningful rather than nominal; and mutation always creates a new message rather than modifying one in place, which is what turns the whole system into an event-sourced log almost for free.
The mechanics follow directly. A DID is, simultaneously, an identifier, a lookup key, and an execution handle — a cmdlet receives a DID, resolves it through LiteDB, processes the underlying message, and emits a new DID representing the result, so a pipeline reads as DID₁ → Cmdlet → DID₂ → Cmdlet → DID₃, structurally identical to the classic PowerShell object pipeline except that what’s flowing is an identity, not an object. LiteDB, one instance per agent, is the system of record — persistent storage, indexing by DID, versioning, retrieval — with a transparent cache layered on top for hot messages, sized and managed independently of execution logic. Runspaces stay fully isolated: no shared memory, only DID strings crossing the boundary, execution stateless between invocations, and cross-runspace “communication” is really just two runspaces independently resolving the same DID against the same LiteDB store. Because every message is immutable and every transformation produces a new version, the system accumulates a complete, replayable event history essentially as a side effect of how it does ordinary work — which in turn gives you your failure-recovery story for free: persistent message logs, replay capability, and idempotent cmdlet execution mean a crashed or interrupted operation can always be resumed from its last durable state rather than requiring bespoke recovery logic per operation.
LOBEs reappear here in their concrete, implementation-level form: modular execution extensions implemented as PowerShell modules, providing cmdlet composition, external system integration, DID-based message processing, and execution-graph augmentation. External integration itself runs through what the whitepaper calls MCP-I — a bridge for external APIs and systems that lets the agent query external databases, call other agents’ APIs, and integrate distributed services while keeping every interaction DID-addressed, so an external system call looks, from inside the agent, exactly like any other DID resolution. Security follows the same pattern: DID-based identity verification, controlled execution boundaries, and module isolation enforced at the LOBE level, rather than a bolted-on permissions layer sitting outside the execution model.
None of this is abstract theorizing divorced from a diagram — the whitepaper explicitly anchors itself to the same DIDLibOS Architecture Reference Model diagram that underlies the AARM discussion above, tying the formal specification back to the conceptual model of multi-agent neural execution topology, DIDComm messaging fabric, LOBE-based computation layers, and neuro-symbolic orchestration. Read together, the whitepaper and the user-group transcript aren’t redundant — the transcript is where the reasoning gets stress-tested in real time against skeptical questions (why not just reuse existing DIDComm discovery mechanisms? why invert the DID authority/method structure? what about wire compatibility?), and the whitepaper is where the surviving decisions get written down as a stable, versioned contract that an implementation can actually be built against.
From Operating System to System Architecture: The DSA and the TDA
Everything above describes a runtime model. The Decentralized System Architecture (DSA) is where that runtime model gets deployed as an actual, running federation.
At the federation level, Web 7.0 provides general-purpose decentralized identity infrastructure: DID Document management conformant to the W3C spec, Verifiable Credential issuance and lifecycle management against W3C VC v2 JWT, full-spec DIDComm v2 encrypted messaging, an append-only RFC 6962 Merkle audit log, UTXO-based token accounting, and GDPR Article 17 erasure support. I want to be clear that the first four of those capabilities stand entirely on their own — any organization could adopt DID management, VC issuance, DIDComm messaging, and Merkle-log auditability without touching the monetary layer at all. The monetary layer, when an organization does want it, is Sovrona, the Shared Reserve Currency for the Web 7.0 ecosystem, ticker SVRN7, implemented as an embeddable .NET 8 library managing citizen and society wallets under a governance-controlled, three-epoch monetary lifecycle, with a cryptographically tamper-evident audit log of every transaction. What makes Sovrona different from both traditional and most existing digital currencies is that it’s built on self-sovereign identity from the ground up: every participant is a DID holder, every entitlement or endowment is a Verifiable Credential, and trust between parties rests on standards-based cryptographic proofs rather than on either a shared blockchain or a central authority.
Because the DID method is configurable, the same library is usable in domains that have nothing to do with SVRN7 currency at all. A hospital consortium can run each hospital as its own DID method, with patient VCs issued by one hospital verifiable by any other, a Merkle log providing an auditable issuance record without exposing patient data, and DIDComm handling encrypted inter-hospital referral messages. A manufacturing supply chain can give each tier-1 supplier its own DID method, with components carrying VC provenance records signed by the manufacturer’s DID and the UTXO model repurposed to track component custody rather than currency. A federation of professional bodies — law societies, medical councils, engineering institutes — can each own a DID method and issue member credentials that verify across bodies through the same DID resolver routing the SVRN7 library already needs. And multiple municipal or provincial government identity systems can let citizens hold identities under their own jurisdiction’s method while cross-jurisdiction services verify credentials without a central identity broker in the loop. The monetary case is the one I’ve built out furthest, but it’s a special case of a much more general federation pattern.
Reading the DSA Diagram
The DSA, in its current version, is a single architecture diagram — captioned “Safe, Secure, Trusted, DID-native, DIDComm-native Web 7.0 DIDLibOS,” scoped to Epoch 0, the Endowment Phase of Sovrona’s monetary lifecycle — and I’ve spent considerable effort making sure that every component drawn in it maps cleanly onto real, working code (specifically, the SVRN7 v0.7.1 C# library) rather than staying aspirational. Reading it left to right, it resolves into seven structural zones, each with a clean role boundary and no overlap in responsibility with its neighbors.
Zone one is the human-facing surface: command-line interfaces across Windows, Linux, Android, iOS, and FireOS, plus a smartwatch UX — the entry points where human intent enters the system, with no agent logic executing at this layer at all. Zone two is a transport-agnostic bridge — Internet, LAN, and peer-to-peer treated equivalently, because DIDComm’s envelope security already makes the transport layer untrusted and interchangeable by design; it simply doesn’t matter which pipe the encrypted envelope travels through. Zone three is the LOBE layer — two LOBE blocks flanking a central SVRN7 label, which is a genuine architectural statement, not a layout accident: the Shared Reserve Currency is positioned as a cognitive capability every runspace can call directly, not as an external service that has to be reached through message-passing. In the current implementation those LOBEs are Svrn7.Federation.psm1 (35 cmdlets) and Svrn7.Society.psm1 (15 Society-native cmdlets), both loaded once into the runspace pool’s shared session state at startup, with an implied third slot for domain-specific extensions — Society.Medicine, Society.Education, and so on — that get added as new LOBEs rather than as modifications to existing agents.
Zone four is the Citizen/Society Trusted Digital Assistant itself — the green outer box containing a red inner box (the PowerShell Runspace Pool, with Agent 1 through Agent N slots and a named DIDComm Message Switchboard) and a purple box at the edge (the DIDComm/HTTP Listener). Zone five is a standard internet cloud bridging that Listener to the wider federation, with explicit inbound-unpack and outbound-pack operations annotated at the boundary. Zone six is the storage layer beneath the TDA: four LiteDB databases (fast cache, long-term message memory, DID document registry, VC document registry), plus a planned Neo4j graph store reached via Cypher and a planned SQL Server store reached via TDS, alongside a dedicated SVRN7 transfer channel connecting the LOBE layer straight to the Sovrona terminal. Zone seven, the largest visual element in the diagram, is the VTC7 mesh: five Citizen TDA nodes connected through purple DIDComm-secured connectors into a federated web, drawn as recursive — every peer in that mesh runs the identical software at the identical architectural level. There is no central broker anywhere in zone seven. Cross-Society communication happens exclusively through each peer’s own Listener instance, never through a shared database, and VTC7 membership itself is enforced by the LOBE layer rather than by network topology: a TDA is a legitimate member of the mesh if it can present a valid Society DID and a current membership credential, full stop.
Inside the TDA
Zone four is worth taking apart in detail, because it’s the design I’ve carried furthest toward an actual implementation specification, and it’s the piece of this whole chapter that most concretely answers the question “what does a Trusted Digital Assistant actually do, mechanically, when a message arrives.”
The Listener and the Runspace Pool are deliberately separate systems that share no threads. This is not an implementation convenience; it’s a load-bearing design rule. The Listener’s only job is to receive a packed message at a minimal Kestrel HTTP endpoint (POST /didcomm), unpack it at the cryptographic boundary — JWE decrypt, then JWS signature verify — and enqueue the unpacked body into a durable inbox. It never executes agent logic, and if unpacking fails at either step, the message is rejected with a 400 and never enters the inbox at all. Symmetrically, outbound messages are packed (JWS signed, then JWE encrypted, using SignThenEncrypt as the default pack mode throughout) only at the Listener boundary, on the way out. The consequence of holding that line strictly is that agent runspaces never touch a cryptographic key and never see anything but verified plaintext — a security guarantee and an architectural simplification arriving together. A slow or misbehaving agent can never block inbound receipt, because it has no path to the Listener’s thread; a burst of inbound traffic can never exhaust the runspace pool, because the Listener does nothing but enqueue.
Sitting inside Agent 1’s runspace — always kept open, always at least one instance running — is the component I consider the single most important piece of the whole TDA design: the DIDComm Message Switchboard. It is the sole reader of the durable inbox; no other agent is permitted to poll it directly. On each cycle it dequeues a batch of messages, checks each one for a cached, already-processed receipt (idempotency, so a retried delivery never gets executed twice), checks the current governance epoch, and routes by DIDComm protocol URI to the appropriate agent runspace — an invoicing message to the Invoicing agent, an onboarding message to the Onboard agent, a trading message either forward or rejected outright depending on whether the epoch permits trading yet. Four specialized sub-agents live alongside the Switchboard inside Agent 1: Email, Calendar, Presence, and Notifications — wrapping, respectively, Microsoft Graph or Exchange mail access cross-referenced against Society member DIDs, calendar events that can carry did: identity claims linking appointments to governance meetings, a presence-publishing protocol broadcasting availability to VTC7 peers, and an alerting subsystem watching inbox depth, balance changes, VC expiry, and wallet-overdraft triggers. Beyond Agent 1, task-specific runspaces handle Onboard (citizen registration), Invoicing (transfer and payment processing), and — inactive until a later governance epoch unlocks it — Trading. Each of Agents 2 through N is opened from the pool on demand and returned when its task completes, so the pool’s capacity is occupied only for the actual duration of work, never held idle by a waiting agent.
Governance is enforced through the epoch mechanism I mentioned above, and it’s worth being concrete about what it restricts. In Epoch 0 (Endowment), citizens may transfer value only to their own Society’s wallet or to the Federation wallet — no citizen-to-citizen transfers across Societies, no open trading. Epoch 1 (Ecosystem Utility) opens cross-Society citizen-to-citizen transfers and activates the Trading agent. Epoch 2 (Market Issuance) opens full open-market operations across the VTC7 mesh. The Switchboard is where this rule gets enforced in practice — it rejects any message type not permitted under the current epoch with a proper DIDComm error response rather than silently dropping it, which matters for auditability: a rejected transfer leaves a trace, a dropped one doesn’t.
Underneath all of this sits the storage tier: five LiteDB databases (the core wallet/UTXO/citizen/society store, a DID registry, a VC registry, a message inbox, and a fast cache), plus the two not-yet-implemented stores (Neo4j for VTC7 trust-path graph queries, SQL Server for relational reporting and regulatory export) that round out zone six of the diagram. A dedicated transfer channel — the SVRN7 XFER rail — connects the LOBE layer directly to the UTXO settlement path, and it exists as a separate channel specifically so that monetary operations never contend with ordinary DIDComm message I/O for the same LiteDB file lock. That’s a small detail, but it’s the kind of small detail that separates an architecture diagram from a system that survives production load.
I’ll draw out five design principles from this that I think generalize well beyond SVRN7’s specific implementation, because they’re really about what it means to build any Trusted Digital Assistant honestly. First, the Listener and the execution pool must be separate systems with no shared threads — receipt and processing are different concerns and mixing them creates cascading failure modes. Second, there must be exactly one reader of the durable inbox, so that idempotency, epoch enforcement, and routing all have a single point of truth rather than being re-implemented, and potentially re-implemented inconsistently, in every agent. Third, packing and unpacking happen only at the boundary — agents work with plaintext, full stop, and never need cryptographic material at all. Fourth, a capability like a shared currency system belongs in the LOBE layer as a cognitive faculty available to every agent by direct in-process call, not buried inside one agent as if it were that agent’s private business. And fifth, every peer in a federated mesh should be structurally identical — the same software, the same architectural level, no privileged central node — because that symmetry is what makes the system self-hosting and recursive rather than dependent on infrastructure that only one party controls.
Locator DIDs and Identity DIDs: The Discipline Underneath It All
I want to end this chapter on something narrower and more technical than everything above, because it’s easy to read the sweep of Pando, AARM, DIDLibOS, and the DSA and miss the small naming discipline that makes the whole DID-exclusive premise coherent in the first place. If every value passed around this operating system is a DID — every parameter, every execution handle, every persisted message key — then it matters enormously whether a given DID string names an entity or points into a sub-resource belonging to that entity. Conflating the two is exactly the kind of category error that, at OS scale, turns into subtle security bugs and broken resolution logic. So I worked through, field by field, three of the most common document types in this ecosystem — a DID Document, a Verifiable Credential Document, and a DIDComm Message — and classified every DID-valued field as either an identity DID or a locator DID.
The governing rule turns out to be strikingly simple, and it holds uniformly across all three document types: a DID with no fragment (#) or query (?) is always an identity DID — it names an entity. A DID with a # or a ? is always a locator DID — it navigates to a sub-resource of that entity. That’s the whole rule, and once you have it, classifying any field in any of these documents becomes mechanical rather than a judgment call.
In a DID Document, the root id is always an identity DID — it names the subject the document describes. controller is always an identity DID, naming whichever entity controls this document. alsoKnownAs entries are identity DIDs, naming equivalent identifiers for the same subject. But the moment you get into verificationMethod, authentication, assertionMethod, capabilityInvocation, capabilityDelegation, and keyAgreement — anywhere a fragment identifier like #key-1 appears — you’ve crossed into locator territory, because those fields are pointing at a specific key or capability within the identity, not naming a separate entity. service entries are locators too, by the same fragment logic, while their serviceEndpoint values are plain retrieval URLs sitting entirely outside the DID identity/locator taxonomy — they’re not DIDs at all, just addresses telling you where to send an HTTP request.
A Verifiable Credential Document follows the same pattern with one field that trips people up more than any other. The document’s own id, the issuer.id, and the credentialSubject.id are all identity DIDs — they name the credential envelope, the issuing party, and the subject the credential is about, respectively. Any DID reference nested inside a claim — credentialSubject.memberOf, say — is also an identity DID, naming the organization being claimed as a membership. But credentialStatus.id is a locator, and it’s the one that goes unrecognized most often: it doesn’t name an entity at all, it points into a status registry to retrieve this specific credential’s current revocation state. Same with proof.verificationMethod (or cryptoseal[].verificationMethod, depending on which proof format you’re using) — a locator pointing at the specific key inside the issuer’s DID Document that produced the signature.
A DIDComm Message skews almost entirely toward identity DIDs, which makes sense once you see the pattern: a message is fundamentally about who sent it and who it’s addressed to, not about navigating into anyone’s sub-resources. from and to are identity DIDs. from_prior.iss, .sub, and .aud — the fields used during DID rotation, to prove a new DID is a legitimate successor to an old one — are identity DIDs too. The message’s own top-level id is typically a URN UUID, not a DID at all, sitting outside the identity/locator taxonomy entirely and simply serving as a thread-independent message identity. Locators only appear in a DIDComm Message where the payload explicitly navigates into a sub-resource — an attachment link carrying a ?service=CredentialRegistry query, for instance, or a verification-method reference buried inside an attached cryptoseal.
I don’t think this is a pedantic footnote to the architecture — I think it’s close to the foundation of it. DIDLibOS works because a DID can serve, interchangeably, as an identifier, a lookup key, and an execution handle. That interchangeability only stays safe if the system — and the humans reading and writing these documents — can tell at a glance whether a given DID string is naming something or pointing at a piece of it. Get that wrong at the OS layer, where DIDs are the only thing passed between cmdlets, and you don’t get a cosmetic bug. You get a system that resolves the wrong thing, silently, at the layer everything else is built on top of.
Closing
Put the four pieces of this chapter back together and what you have is a genuinely complete stack, running top to bottom on one substrate: a person who remains in Self-Sovereign Control of however many digital personas they choose to project, each persona served by its own Trusted Digital Assistant; those assistants running as neuromorphic agents under the AARM, built from dynamically loadable LOBEs, communicating by reference over DIDComm 7.0; the whole thing hosted on DIDLibOS, a polyglot, DID-exclusive library operating system where identity itself — not compute, not the UI, not even the AI model doing the reasoning — is the foundation the rest of the stack is built on; deployed, at federation scale, as the Decentralized System Architecture, with citizen and Society TDAs meeting each other as structurally identical peers in a VTC7 mesh, governed by an epoch model that can be tightened or loosened without touching the code underneath it; and held together, at the field level, by a naming discipline precise enough that every DID string in every document has one unambiguous meaning.
That last point is the one I’d ask a reader to sit with the longest. It’s tempting to treat “identity-first” as a slogan, the way “decentralized” got treated as a slogan for most of the last decade. What I’ve tried to show in this chapter is that taking identity-first literally — building an operating system where the DID isn’t a field in a profile but the actual unit of computation — forces a cascade of decisions that a conventional, app-first or AI-first architecture never has to make: how memory persists, how agents communicate, how currency moves, how governance is enforced, and even how you punctuate a string so a machine can tell an entity from a pointer. Windows was device-first. iOS was app-first. The current generation of AI platforms is intelligence-first. Pando, DIDLibOS, and AgenticOS are my answer to what an identity-first operating system looks like when you actually build it end to end — and the Trusted Digital Assistant, running quietly inside a Citizen’s runspace pool, unpacking and packing DIDComm messages at a boundary it never lets anything else cross, is where that answer becomes something you can run.
Chapter 9: Parchment Programming: Designing Software for the AI Era
I have spent thirty-some years moving code across representations — pseudocode into source, source into intermediate language, intermediate language into byte code, diagrams into classes, classes into running systems. For most of that career I never had to ask what was actually happening at each hand-off, because the answer was always the same: a human being sat in the middle and translated. The human read the diagram, held it in working memory, and typed the code. The translation was slow, but it was at least consistent in one respect — the same person who understood the intent was the person producing the artifact.
That is no longer true. I now spend most of my working day generating C#, PowerShell, Markdown, and architecture diagrams in the same conversation with an AI coding assistant, and the assistant is not the same “person” who understands my intent — it is a transformer with no persistent memory, reconstructing my intent fresh from whatever tokens happen to be sitting in its context window at that moment. Somewhere in the last two years, the question of what happens between representations stopped being a philosophical aside and became the central engineering problem of my day-to-day practice. This chapter is about that problem, a methodology I built to solve it, and what I now believe is a genuinely new answer to a very old question: what is the right form for a software specification when the reader of that specification is sometimes a human and sometimes a machine, and the machine forgets everything the moment the conversation ends?
I call the problem the Discontinuous Code Transformation problem, or DCT. I call the methodology Parchment Programming. Both grew out of the same year of hands-on work building the Web 7.0 Trusted Digital Web stack — DIDComm agent architectures, the SVRN7 solution, the DIDLibOS runtime — using Claude as a daily coding partner. What follows is the argument in the order I actually arrived at it: first the diagnosis, then a concrete diagnostic exercise that forced me to understand what an AI coding assistant really is, then the methodology itself, then the question of what visual language it should be expressed in, then what it implies for how software gets built going forward, and finally, the payoff — how Parchment Programming actually closes the gap the DCT problem opens up.
The Discontinuous Code Transformation Problem
Coding is a process of Discontinuous Transformation. That is the whole claim, stated as plainly as I can state it: whenever code moves from one representation to another, something is lost, and the losses cluster wherever a human sits in the middle of the transformation.
I started cataloguing these transformations almost as an act of housekeeping — a way of making visible something I had always sensed but never written down. The first pass produced a flat list of sixty-one distinct code transformations I could identify from my own practice and from the wider literature of computing: ideas into source code, ideas into pseudocode, ideas into prompts, pseudocode into source code, algorithms into source code and back again, source code into optimized code, into executable code, into intermediate code, into object code, into virtual machine byte code (the JavaVM, the .NET Runtime, the Ethereum VM), into an AST, into “nocode,” into documentation. Old source code into new source code. Source code into buggier code, and — with luck — into cleaner code. SQL into CSV/XML/JSON. GraphQL and Cypher into datacode. .NET objects serialized into datacode. REST/HTTP codes into datacode. Source code into firmware, into microcode, into silicon. Blockchain code into cryptocurrency codes and into Verifiable Data Registry codes. Decentralized Identifiers into DID Documents. Verifiable Credential code into secure, trusted, verifiable document code. And then, at the edges of the list, the transformations that leave the machine entirely: human gestures into sign-language code, sign-language code into what I called neuralcode, five senses into and out of neuralcode, neuralcode into muscle-code gestures, reading code into neuralcode, muscle-code gestures into keyboard code. The list runs the full distance from a thought in someone’s head to a keystroke on a physical keyboard, and every single link in that chain is a transformation, and every transformation is an opportunity for loss.
The list by itself was not an argument, just an inventory, so I went back and organized the sixty-one items into six orthogonal, spanning-set categories, because a flat list of sixty-one things tells you there is a lot going on but not what kind of thing is going on. The six categories are: Abstract ⇄ Formal Code, covering the movement between intent, design, ideas, algorithms, pseudocode, and prompts on one side and formal executable code on the other — fifteen items, and this is the category that matters most, because it contains the transformation at the very top of the list, ideas into source code, which is the one every other transformation ultimately serves. Code Representation & Structure, nine items, covering transformations that change the internal shape of code — into optimized code, into an AST, into byte code — without changing its fundamental semantics. Code Quality & Behavioral Transformation, five items, covering the difference between old code and new code, buggier code and cleaner code, slow code and fast code — the category where regressions live. Code Data, Formats & External Artefacts, ten items, covering the constant traffic between code and the data formats and structured documents it produces and consumes — SQL to datacode, .NET objects to XML/JSON, DIDs to DID Documents, Verifiable Credentials to trusted document code. Execution Context, Platforms & Environment, twelve items, covering the movement of code across repositories, runtimes, and physical substrates — local code to GitHub and back, source code to firmware, to microcode, to silicon, to simulated environments. And Human-Cognitive & Sensory Interfaces with Code, ten items, covering the boundary where code stops being code at all and becomes something a human perceives or produces with their body — text to speech, gestures to sign language, sign language to neuralcode, reading to neuralcode, muscle code to keystrokes.
Laid out this way, the pattern is visible in a way it was not when the sixty-one items were just a list: the categories are not equally dangerous. Category 2, representation transformations like source-to-AST or source-to-bytecode, are handled by compilers and interpreters — deterministic machines built for exactly this purpose, and they do not lose information in any way that matters, because they were engineered not to. Category 5, execution-context transformations, are largely solved by tooling — build systems, version control, cross-compilation. But Category 1 — ideas into source code, ideas into pseudocode, ideas into prompts — has never had a deterministic machine sitting in the middle of it. It has always had a human. And Category 6, the human-cognitive interfaces, is where the discontinuity is most literal: neuralcode, whatever is actually happening inside a human skull as an idea takes shape, has no formal grammar at all. It cannot be parsed. It can only be interpreted, imperfectly, by whoever receives it next.
So the diagnosis condenses to a single sentence, and I want to state it exactly the way I first wrote it, because the whole rest of this chapter is an argument about what to do in response to it: coding is a process of Discontinuous Transformation, and the coding process becomes discontinuous whenever there is a human in the middle. Not because humans are bad at their jobs. Because human interpretation is, structurally, a lossy and non-reproducible transform. Two architects reading the same requirements document produce two different designs. Two developers reading the same design diagram produce two different implementations. Every one of those readings inserts assumptions the original author did not state, resolves ambiguities the original author did not anticipate, and quietly discards details the original author considered essential and never wrote down because they seemed too obvious to mention. Multiply that loss across the ideas-to-pseudocode step, the pseudocode-to-source step, the design-review step, the code-review step, and the maintenance-six-months-later step, and you get the actual, felt experience of enterprise software development: specifications that drift from implementations within weeks of being written, diagrams that nobody trusts because nobody has kept them in sync with the code, and systems whose true behavior lives only in the heads of the two or three engineers who have read the source code recently enough to remember it.
The obvious next question, the one I did not yet have a good answer to when I first wrote the DCT problem down, is: what replaces the human in the middle? Not “how do we make humans better translators” — thirty years of software methodology has already tried that, with mixed results — but “what is the artifact, and what is the process, that eliminates the discontinuity rather than merely managing it?” Before I could answer that, I needed to understand something more basic: what an AI coding assistant actually is, mechanically, when it sits where the human used to sit. That question turned out to be the diagnostic exercise that cracked the whole problem open.
A Diagnostic Question: What Does Claude Actually Have?
In April 2026 I was deep into a real solution — SVRN7, a live, ~13,500-line, seven-project C#/.NET codebase with forty-five files, two hundred and seven tests, twelve interfaces carrying a hundred and ninety-one members, a hundred and nine concrete classes, records, and structs, fifty-five async methods, thirteen exception types, and a public driver interface with forty-one members. Over the course of a long working session I had asked Claude to generate source code, write the README, produce test cases, and draw an ArchiMate architecture diagram, all from the same running conversation. Everything it produced was coherent — the diagram matched the code, the README matched the tests, the tests matched the interfaces. It looked, from the outside, exactly like the output of a tool with a real model of the software sitting behind it.
So I asked it directly: what is your internal representation of this solution? Is it an AST? Is it the actual source code? Some other modeling approach, some metamodel, that you’re using to generate the code, document the README, create the test cases, draw the architecture diagrams? I wanted a straight answer, and I got one, and the answer reshaped how I think about every artifact I now hand to an AI coding assistant: there is no persistent internal representation at all.
Mechanically, an AI coding assistant like Claude is a transformer that maps a context window — a flat sequence of tokens — to a probability distribution over the next token. There is no AST sitting behind that process. No object graph. No schema. No database. No symbol table. When the conversation session ends, nothing persists; the model’s weights are fixed and do not change based on what happened in the session. What substitutes for a representation, during the conversation itself, is the context window — every message, every code block, every README excerpt, every test name that has scrolled past is sitting in active context as raw tokens, and when the assistant generates a diagram or a README or a test file, it is pattern-matching against that token sequence and against the statistical regularities in its weights that encode general knowledge of C#, of ArchiMate’s Open Exchange Format XML, of W3C Verifiable Credentials, of DIDComm v2, and so on.
The reason the outputs looked coherent — the diagram agreeing with the code, the README agreeing with the tests — was not that a shared model was driving all three. It was that a compacted summary sitting at the top of the conversation, a document I had written in a previous session specifically to act as a faithful briefing note listing the files, the tests, the interface members, the bugs fixed, was doing the work an architecture model would normally do. Every downstream artifact was, in effect, a translation of that natural-language briefing document through the model’s weights. Coherent, in the sense that a careful human author holding the same briefing document in their head would also produce coherent, mutually consistent artifacts. But not coherent in the way a proper model-driven-engineering toolchain is coherent, where every artifact is mechanically derived from one authoritative source and a change to that source propagates automatically everywhere else.
What the assistant explicitly does not have: no parse tree or AST of the actual C# source; no type graph, dependency graph, or call graph; no formal metamodel instance — no MOF, no Ecore, no ArchiMate metamodel objects sitting anywhere; no semantic index of method signatures; and no persistent memory between sessions, which is exactly why the compacted briefing document had to be written in the first place, to bridge one session’s understanding into the next. And the practical consequence follows immediately: if the C# source and the ArchiMate diagram ever diverge, neither one will notice and neither one will self-correct. Nothing “syncs.” You have to notice the divergence yourself, bring both artifacts back into a context window, and ask the assistant to reconcile them by hand, all over again, every time.
I want to be precise about why this diagnostic matters to the rest of the chapter, because it would be easy to read it as a narrow technical curiosity about how transformers work. It is not that. It is the discovery that the AI sitting in the middle of my coding process is not, by default, a deterministic machine of the kind that turns source code into an AST. It is closer, structurally, to the human it is replacing: a reader that reconstructs meaning from whatever is placed in front of it, session by session, with no memory and no ground truth beyond the tokens currently in view. If I hand it a vague prose specification, it will interpret that specification exactly the way a human developer would — filling gaps with plausible assumptions, silently inventing what was not stated. The DCT problem does not go away just because I replaced the human translator with an AI translator. It only goes away if I change what I am handing across the translation boundary — if I stop handing over prose that requires interpretation and start handing over something that can be read directly, without interpretation, the same way every time. That is the design constraint Parchment Programming was built to satisfy.
The Parchment Programming Methodology
Parchment Programming is an architecture-first software development methodology in which a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation, the IR, that an AI coding assistant reads directly to generate correct, idiomatic code. Rather than translating requirements through layers of prose specification, the diagram itself encodes stereotypes, interface contracts, project boundaries, data models, and protocol annotations in a form that is simultaneously human-readable and AI-actionable.
The starting point is a fact about how Claude actually consumes a conversation: it receives images and text together, in one context. Claude can see a diagram image and reason about it. Claude can read structured Markdown and text with full fidelity. But Claude cannot cross-reference between an image region and a text table by coordinate — it does not point at pixel (340, 210) and look up row seven of a table. It reasons about both, image and text, holistically, as two bodies of evidence sitting side by side in the same context. Once I understood that, the design fell out almost mechanically: let the diagram carry spatial and structural truth — what exists, what contains what, what connects to what — and let a companion document carry behavioral and contractual truth — what each thing does, what its lifecycle is, what schema it obeys, what happens when it fails. That is a clean separation of concerns, and it is the architectural spine of the whole methodology.
In practice this becomes a small, disciplined bundle of artifacts: a diagram.png, the visual, carrying spatial truth; a PARCHMENT.md, the master specification, carrying behavioral truth; and a schemas/ folder holding the JSON schemas referenced from the Markdown — a DIDComm envelope schema, a DID document schema, a VC document schema. The PARCHMENT.md is the primary AI coding input. The diagram is not appended to it or linked from it — it is embedded directly at the top of the document, so that when Claude reads the file, it sees the architecture as the structural foundation before it reads a single annotation.
The internal structure of a well-formed PARCHMENT.md follows a fixed shape I have converged on through iteration: a system identity section giving the specification DID, the epoch, the version, the target runtime, and the codegen mode; a component fact table, one row per major component, with columns for artifact, lifecycle, multiplicity, and thread-safety; a connector/protocol index mapping every “from → to” relationship to a protocol, a payload type, and a schema reference; a data-contracts section giving the key structure, TTL, and field list for every store; a trust-boundary-policies section spelling out, in plain language, what each color-coded zone requires — green zone, internal to the trust boundary, integrity only; purple zone, DIDComm-authenticated, everything must be sign-then-encrypt; yellow zone, open internet, untrusted until the DIDComm envelope validates; an AI codegen manifest mapping each component to a generation mode — AI-generated, AI-scaffolded, or hand-authored — and an acceptance criterion; and, critically, an open-questions log.
That last section is, in my judgment, the single highest-leverage piece of the whole document, because it directly targets Claude’s most damaging failure mode when it is coding from an underspecified input: silent invention. An AI that hits a gap in a specification does not stop and ask — it fills the gap with something plausible and keeps going, and the plausible-looking fill is often wrong in ways that are expensive to discover later. Naming the unknowns explicitly — is LOBE hot-reload supported, or does it require a restart; what is the Fast Cache eviction policy when LiteDB is full; is the CIPHER algorithm fixed to Ed25519 or negotiated — instructs the assistant to emit // TODO: [OPEN QUESTION — …] directly in the generated code rather than quietly deciding the answer itself and moving on.
Three further conventions make this reliably actionable for an assistant with no persistent memory. First, treat the diagram as a spatial index and not a specification in its own right — in the prompt itself, I say something close to: the diagram shows containment and flow; the PARCHMENT.md sections are authoritative for all behavioral detail; where they conflict, the Markdown wins. That single sentence prevents Claude from over-reading visual ambiguity as if it were a decision. Second, keep the behavioral sections machine-parseable — tables and bullet lists, not prose paragraphs, for anything that is meant to drive code generation, because Claude parses structured Markdown far more reliably than it extracts structure from paragraphs. Third, submit the diagram and the PARCHMENT.md together, in full, in every coding prompt — because, as the diagnostic exercise established, there is no persistent memory between sessions, so the complete parchment has to be present every single time, and the compact table format keeps that affordable in token terms.
One further refinement worth carrying forward: rather than cluttering a single master diagram with every possible annotation, maintain lightweight overlay variants alongside it — the master diagram unchanged, plus a diagram-trust-zones.png carrying colored zone overlays, plus a diagram-dataflow.png carrying a numbered flow sequence. These are cheap to produce with ordinary tools — PowerPoint or draw.io layer toggles — and each one gives Claude a focused lens on the same underlying architecture without forcing the master diagram to carry every concern at once. Annotating the master diagram directly is worth avoiding; a companion document with no diagram at all loses the spatial and structural truth the diagram alone provides. The diagram embedded in the PARCHMENT.md is the right baseline, and diagram-plus-overlays-plus-PARCHMENT.md is the right answer for anything sufficiently complex. The PARCHMENT.md is the intermediate representation. The diagram is its most important section — but it is only one section of it.
Optimizing the Diagram: The Diagrammatic Design Document as Intermediate Representation
Having settled the shape of the surrounding document, I turned to the diagram itself and asked a more exacting question: given a real, working architecture diagram — in my case, the DIDComm Agent Architecture Reference Model diagram for the Trusted Digital Assistant — how would you actually optimize it as a design document and intermediate representation for an AI-coded system? I put the question to Claude directly, against the live diagram, and worked through the answer twice, refining it the second time against the added constraint of a specific target: a Claude-coded C#/.NET 8 system.
The diagram was already doing several things well. Its layered containment — Trusted Digital Assistant containing a Runspace Pool containing Agent Runspaces — maps cleanly onto a class and module hierarchy an AI can scaffold directly. Its named protocols — DIDComm V2, REST/HTTP, SQL/TDS, CIPHER — give the AI concrete interface contracts to target rather than generic ones. Its technology bindings — LiteDB, Neo4j, SQL Server, PowerShell modules — eliminate the ambiguity that would otherwise force the AI to guess at dependency selection. Its directional flow, inbound unpack through the switchboard to outbound pack, implies a pipeline pattern the AI can instantiate without being told to. Its multiplicity hints — Agent 1…N, Citizen TDA ×4+ — signal where collection types and polymorphism are required.
But six gaps stood between “architectural sketch” and “generatable specification.” The diagram showed what existed but not how many or when — was the runspace pool fixed-size or elastic, were LOBEs loaded at startup or on demand, did agent runspaces share state or run fully isolated — and the fix was a component fact table, one row per major component, columns for multiplicity, lifecycle, state ownership, and thread-safety. Interface contracts were implied rather than declared — a connector arrow labeled “DIDComm/HTTP Listener” carries no method signature, no message schema, no error contract — and the fix was stereotyping every connector with something like «sends: DIDCommEnvelope», backed by a legend mapping arrow style to message type and schema reference. There was no representation of error or exceptional flow at all — only the happy path, which produces brittle code with no fault boundaries — and the fix was a fault-boundary overlay: dashed red borders around components requiring retry or circuit-breaker behavior, paired with a short failure-mode legend spelling out what happens when CIPHER fails, when LiteDB is unavailable, when a DIDComm unpack throws. The data model was storage-only and schema-less — four LiteDB stores shown with no schema, key structure, or TTL, which leaves the AI to invent schemas on its own — and the fix was a data-contract sidebar giving the primary key pattern, the top handful of fields, and the eviction policy for each store. Security and trust boundaries were structural but not behavioral — the CIPHER block and the federation boundary were visible, but the enforcement rules were not, so it was unclear when encryption applied or who could authorize a new module load — and the fix was an explicit trust-boundary annotation layer: color-coded zones with a legend and a one-line policy statement at every zone crossing. And finally, and this is the gap I consider the actual core of Parchment Programming as distinct from ordinary architecture diagramming, there were no prompt-injection anchors at all — no indication of which boxes mapped to which code artifacts, which interfaces had to be hand-authored versus AI-generated, or what the acceptance criteria were per component — and the fix was the AI codegen manifest: component, target artifact, generation mode, acceptance test, laid out as a table.
Working through the diagram a second time, against the sharper target of Claude-coded C#/.NET 8, produced a further, more granular layer of recommendations, all in service of the same underlying goal — closing the distance between what a human architect sees when they look at the box-and-arrow drawing and what an AI needs in order to emit correct code without guessing. Every box should carry an explicit stereotype rather than leaving Claude to infer whether it represents an interface, a class, a hosted service, or a background worker — «HostedService» RunspacePoolService, «Router» DIDCommSwitchboard, «Repository» FastCacheRepository : LiteDB. Every arrow should carry not just direction and protocol but the actual C# interface name it implements — Agent Runspace → Fast Cache : IFastCacheRepository. The diagram should declare an explicit .NET project boundary map, a legend translating colored regions directly into .csproj names, which I consider the single most Claude-actionable addition of all of them, because it resolves namespace and dependency-injection registration questions that would otherwise be answered inconsistently across sessions. Ambiguous multiplicities — Agent 1, Agent 2, Agent N — need a small inset spelling out the actual instantiation model: a factory, the interface it produces, the lifecycle scope. Data stores need their concrete collection types spelled out — ILiteCollection<CachedMessage>, ILiteCollection<DidDocument> — rather than being left as unlabeled cylinders. Protocol modes that matter to correctness, such as a DIDComm default of sign-then-encrypt rather than authcrypt, should be annotated directly on the diagram so the generated code is default-correct without a separate verbal instruction every time. Processing pipelines implied by directional arrows — inbound unpack, route, dispatch; outbound pack, transmit — should be spelled out step by step, because that sequence maps almost verbatim onto middleware registration in Program.cs. And any external subsystem boundary, such as an interface to an outside settlement system, should be marked explicitly as an external subsystem with its own access interface and protocol, so the AI does not conflate it with an internal component.
The ideal shape for each box, distilled from all of this, is compact: stereotype, component name, the interface it implements, the project it belongs to, and one line naming a key method or contract hint. Even applying just the stereotype and the project name to the top-level boxes measurably improves the accuracy of what comes back.
It was worth asking, at this point, whether anyone had already built this. The honest answer is: adjacent ideas exist, but nothing matches Parchment Programming’s specific inversion. Diagram-as-code tools — Structurizr and its C4 model, D2, PlantUML, Mermaid — run in the opposite direction: you write text, and a diagram is generated from it, laid out automatically. The diagram is the output, not the authoring artifact. Tools like Swark go code-to-diagram: an LLM reads retrieved source files and produces an architecture diagram as documentation after the fact — again a byproduct of code, not a driver of it. Tools like Eraser or DiagramGPT go natural-language-to-diagram-to-code, but the diagram in that pipeline is ephemeral, a working scratchpad on the way to a prompt, not a persistent, authoritative specification. Structurizr comes closest in spirit — its model-based consistency makes it attractive for AI-assisted C4 diagram generation — but it is DSL-first, not diagram-first, and it carries no notion of a diagram encoding interface contracts or project-boundary stereotypes for code generation. And academic reverse-engineering work goes code-to-diagram using LLMs to recover static and behavioral architectural views — still the wrong direction. What none of these do is treat a richly annotated visual diagram, authored first by a human architect, as the primary and sufficient authoritative artifact from which an AI generates code directly, without a prose specification standing in between. That specific combination — architecture-first and human-authored rather than AI-generated; carrying code-generation semantics embedded directly in the visual, not bolted on afterward; and replacing the prose specification entirely rather than merely supplementing it — is, as far as I have been able to determine, original.
Choosing a Visual Language
None of the diagram optimization above answers a prior question: optimized in what notation? A Parchment Programming diagram has to do five things at once — encode stereotypes that map cleanly to C# constructs; express layered bounded contexts corresponding to project and namespace boundaries; annotate arrows with interface contracts and protocols; be readable by Claude directly from an image, with no dedicated parser; and be authorable by a human architect without excessive tool friction. I evaluated the candidates against exactly those five requirements, including the notation I had already been using in practice.
My existing style — custom, annotated box diagrams, color-coded regions, nested containment, labeled arrows with protocol annotations — turned out to already be doing most of what Parchment Programming needs. It is human-readable and visually expressive, Claude reads it directly from an image without any conversion step, its nested containment maps naturally onto project boundaries, and it carries no tool lock-in. Its gap is that it has no enforced stereotype vocabulary — Claude still has to infer too much about what kind of thing each box represents — and it is not machine-parseable without a defined grammar. It is the strongest starting point, but it needs formalization, not replacement.
ArchiMate, which I already know well and use for governance-layer modeling elsewhere in this work, is strong exactly where Parchment Programming does not need strength: the motivation, strategy, and business-capability layers, showing why a system exists rather than how to build it. Its stereotype vocabulary — «ApplicationComponent», «ApplicationService», «DataObject» — is standardized and formally defined, and I already have the tooling for it in Archi. But it is too coarse and too business-oriented to drive C# interface and class generation directly; it has no native concept of IHostedService, no notion of middleware, no representation of dependency-injection registration; and critically, Claude reads ArchiMate through its Open Exchange Format XML rather than the visual itself, which loses the directness that is the entire point of Parchment Programming. It is also, frankly, too ceremonial for the pace of iteration this methodology requires.
UML — component diagrams and class diagrams together — is the closest existing formal precedent. The «stereotype» notation is native to UML, Claude has deep training on it and reads it very accurately, and interface contracts are expressible formally. But UML requires two diagram types working together to do what Parchment Programming needs in one view, it has no built-in notion of protocol or messaging annotation, it is verbose in a way that undermines the architecture-at-a-glance quality a parchment needs, and it does not naturally express runtime topology — runspace pools, agent meshes — the way a more free-form box diagram does.
The C4 model, authored through Structurizr or similar tooling, has the right levels — context, container, component, code — and its container level maps well onto .NET project boundaries. But it is DSL-authored or prose-prompted rather than hand-drawn; the diagram is generated output, not the primary authoring artifact, which inverts the entire Parchment Programming authoring model. It also has no stereotype vocabulary tuned to .NET-specific constructs.
The resolution is not to adopt any one of these wholesale but to define a thin, formal PP-native notation on top of the style I was already using: borrow the «stereotype» convention from UML, because Claude reads it natively and it maps directly onto C# constructs — «HostedService» implies IHostedService registered in DI, «Middleware» implies an app.Use…() call in Program.cs, «Repository» implies the IRepository<T> pattern, «Router» implies internal dispatch with no HTTP involved, «Gateway» implies an external system boundary, «Factory» implies a DI-registered factory pattern; borrow the nested-containment model from ArchiMate, so color regions map directly onto project boundaries; keep the box shapes, color coding, and directional protocol-labeled arrows that were already working; and add exactly one new convention, that every arrow also carries an interface name in small text alongside its protocol label. Scored against stereotype support, .NET mapping, Claude readability, and authoring ease, that combination — my existing style plus UML’s stereotype vocabulary — outranks UML alone, the C4 model, ArchiMate, and lightweight text-to-diagram tools like Mermaid or D2, which read beautifully but carry no stereotype or mapping semantics at all. The bottom line is not “adopt a standard” but “formalize a dialect”: the existing visual style is the right foundation, and it becomes the best available notation for AI-driven C#/.NET code generation the moment it is disciplined with stereotypes and interface-bearing arrows.
What PPML Implies for Software Development
Once the notation is fixed and the surrounding document structure is fixed, the combination has a name — the Parchment Programming Markup Language, PPML — and PPML makes a claim considerably stronger than “diagrams are useful documentation.” It asserts that a formal diagram is a sufficient specification for code generation: that if a diagram is conformant — every element uniquely labeled, every element belonging to exactly one type defined in a legend, every element carrying a derivation rule — then an AI or a human can produce the correct implementation from the diagram alone, with no additional prose specification required. That is a claim about sufficiency, not merely about usefulness, and it carries a chain of implications that are worth walking through individually, because each one changes something about how a team would actually work.
The first implication is that the specification artifact itself changes identity. In conventional development, the specification is prose — a requirements document, a design document, an architecture decision record — and the diagram is illustrative, supplementary, and, in most projects I have worked on, chronically stale within weeks of being drawn. Under PPML the diagram is the specification, full stop, and prose documents — design writeups, whitepapers, protocol drafts — are derived from the diagram, explaining and justifying it rather than governing it. If the diagram and the prose disagree, the diagram wins. That inversion means diagram maintenance becomes the primary engineering discipline, displacing prose authorship from that role. A diagram change is a specification change; a code change with no corresponding diagram change is, by definition, undocumented behavior, because tractability has been violated.
The second implication is that AI code generation becomes deterministic at the architecture level. A gap register paired with explicit derivation rules gives an AI generator a closed-world assumption: every artifact it produces must trace back to a specific diagram element instance, and every diagram element instance must produce at least one artifact. There is no more open-ended “build me a messaging system.” There is only a grounded request of the form: derive the artifact for element instance “DIDComm Message Switchboard,” of type Switchboard, following the rule that a Switchboard derivation produces one router class, one protocol registry, and one outbound queue. The AI cannot invent artifact names absent from the diagram. It cannot silently add dependencies. It cannot reorganize the architecture on its own initiative. That constraint is not a limitation on the AI’s creativity — it is the entire point. Creativity belongs in the diagram; precision belongs in the derivation. The practical consequence is that generation quality becomes bounded below by the quality of the diagram rather than by the quality of any individual prompt — a well-formed PPML diagram produces consistent, reproducible results across sessions and even across different AI models, while a poorly formed diagram produces inconsistent results no matter how carefully the prompt is written.
The third implication is that the change process becomes explicit in a way conventional development structurally lacks. Ordinary development has no formal mechanism for distinguishing “we changed the architecture” from “we changed an implementation detail” — both arrive as pull requests indistinguishable from each other at a glance. PPML enforces the distinction by freezing the legend within an epoch: element types cannot change mid-epoch, a new component requires a diagram change, a diagram change requires a version increment, and a version increment requires a gap-register update. Architectural changes become visible precisely because they are diagram changes; refactoring, tuning, and bug fixes inside an already-derived artifact require no diagram change at all. The boundary between architecture and implementation is drawn exactly at the diagram’s edge, which has a direct governance consequence for a project like the Web 7.0 SVRN7 solution: the diagram becomes the governance document, epoch transitions become diagram changes, new protocol support becomes a module addition to the diagram, and the controlling body owns the diagram while contributors derive from it.
The fourth implication is that testing becomes traceable to the diagram in the same way source artifacts are. Every test ought to be traceable to a specific diagram element instance; a test with no corresponding element is either testing an undocumented artifact — a tractability violation — or testing an implementation detail that should never have been exposed in the first place. Practically, this lets the gap register carry test coverage as a tracked property rather than leaving coverage to individual developer discretion.
The fifth implication is that documentation staleness becomes structurally impossible to hide, rather than merely undesirable. In conventional projects, diagrams drift because they are maintained on a separate schedule from the code. Under PPML, a stale diagram is a first-class defect, because the gap register built from it is wrong, and any AI-generated code derived from a wrong gap register will itself be wrong. The resulting discipline is simple to state: diagram first, always. Before a new C# class, PowerShell module, or component descriptor is written, the corresponding element instance has to already exist in the diagram — which is why, in the SVRN7 solution, every generated source file carries a derivation-trace comment naming the exact diagram element and diagram version it was derived from. That comment is not decorative. It is the actual traceability link, and if the named element instance no longer appears in the current diagram, one of the two artifacts — the file or the diagram — is stale, and that has to be resolved before either can be trusted again.
The sixth and final implication is forward-looking rather than descriptive of current practice: the methodology scales with AI capability rather than being made obsolete by it. Right now, the AI assists with derivation — producing C# from a diagram element description, writing scripts from a derivation rule, drafting specification-language sections from an architectural decision — while a human holds the diagram and reviews what comes out of it. As AI capability increases, the human’s role does not disappear; it shifts further toward diagram authorship and review, with the diagram becoming the actual interface between human architectural intent and AI implementation. The better the diagram’s grammar — the legend, in PPML’s terms — the more precisely an AI can translate intent into code without human mediation at every step. A machine-readable component descriptor format, carrying input and output schemas, composition hints, and use cases in a form an AI can reason about without reading the underlying source at all, is an early instance of exactly this pattern: the diagram element produces both the code artifact and a separate AI-legibility artifact, both derived from the same source, and an AI consuming the legibility artifact is one further step removed from needing to read the diagram directly at all. The next step, which PPML anticipates without yet implementing, is an AI that reads the diagram directly and performs full derivation without a human intermediary for routine changes.
None of this is unlimited. PPML is most effective at component-level architecture — what exists, how it relates, what it is responsible for — and considerably less effective at algorithmic detail. A diagram can say that a transfer validator exists and implements a given interface; it cannot say how step four of an eight-step validation sequence detects a replayed nonce, or how a Merkle log is actually constructed, or the exact byte-level sequence of a pack/unpack operation. That is not a flaw in the methodology — it is a boundary condition, and an honest one. PPML governs architecture. Algorithms require their own specification discipline — protocol drafts, pseudocode, formal methods — operating alongside it. The two disciplines are complementary: the diagram tells you what to build and how the pieces connect; the algorithm specification tells you how each piece behaves once you are inside it. The whole of PPML’s implications reduces to one structural claim — the diagram is the primary engineering artifact, and everything else is derived from it — and whether that claim pays off depends entirely on whether the diagram can actually be kept accurate and complete, which is a discipline question, not a tooling question.
How Parchment Programming Solves the DCT Problem
I want to close the loop back to where this chapter started, because that is the actual point of everything above — not diagram hygiene for its own sake, but a direct answer to the diagnosis I opened with.
The DCT problem frames coding as a process of discontinuous transformation and locates the source of the discontinuity precisely: wherever a human sits in the middle. The sixty-one catalogued transformations, spread across the six categories, all share one failure mode underneath their surface differences — each transition is a lossy, ambiguous, context-dependent hand-off, and the most consequential instance of that failure mode by far is the very first transformation on the list, ideas into source code. The human is the discontinuity. My own answer to that diagnosis, when I first sat with it, was three words: remove the human discontinuity. Parchment Programming is the methodology for doing exactly that — not by removing humans from software development, which would be neither possible nor desirable, but by removing the human as the translation layer sitting between architectural intent and generated code.
The mechanism is the elimination of the ambiguous, lossy middle step specifically. In the traditional pipeline, a human architect produces a diagram, and then a separate human developer mentally translates that diagram into code, carrying with them every misinterpretation, every piece of missing context, and every invented assumption that mental translation inevitably introduces. Parchment Programming makes the diagram itself the machine-readable intermediate representation, so that the transformation from architecture to code becomes a direct, AI-mediated step with no human translation layer sitting in between the intent and the implementation. The PARCHMENT.md, with the diagram embedded at its top as the structural foundation and the behavioral detail following in machine-parseable tables — component facts, connector and protocol indexes, data contracts, trust-boundary policies, a codegen manifest — becomes a continuous transformation surface rather than a discontinuous one.
Mapped back onto the DCT categories directly: the diagram plus the PARCHMENT.md takes the place of the human developer’s mental model, making the Category 1 transformation — ideas into source code — direct and deterministic instead of an individually variable creative act. The open-questions log directly targets Category 3, code quality and behavioral transformation, by naming unknowns explicitly and instructing the AI to mark them rather than silently invent behavior that later has to be discovered and corrected as a bug. And the schema references embedded throughout the PARCHMENT.md — a DIDComm envelope schema here, a DID document schema there — make the Category 4 transformations, code into data and external formats, traceable and verifiable rather than implicit, closing off one of the most common sources of silent format drift in ordinary development.
Underneath all of that sits the same clean separation of concerns I described earlier: the diagram carries spatial and structural truth, the PARCHMENT.md carries behavioral and contractual truth, and that split is not incidental — it mirrors how a compiler separates a parse tree, which is purely structural, from semantic analysis, which is purely behavioral, and for the same reason: separating the two reduces the amount of interpretive judgment required at every downstream stage.
The DCT problem, at bottom, is a problem of lossy intermediate representations at every point where a human serves as the translator. Parchment Programming solves it, not by making human translators more careful or more disciplined — thirty years of methodology has already tried that path and it has never closed the gap — but by replacing the human-as-translator with an AI-as-transformer operating on an artifact that is rich enough, and structured enough, to be read the same way every time. The most expensive and most error-prone transition in the entire sixty-one-item catalogue — ideas into source code — stops being a creative act whose outcome depends on which developer happened to read the specification that week, and becomes instead a well-specified, reproducible, AI-mediated step. That is not a claim that software development becomes mechanical, or that architects stop mattering. It is the opposite: it is a claim about where human judgment should actually live in a world where an AI coding assistant has no memory beyond the current context window and no model of your system beyond what you hand it. It should live in the diagram, at the moment of design, where a human is unambiguously the right author — and it should be removed, deliberately and by construction, from the moment of translation, where a human was never actually adding anything except noise.
That is the whole of Parchment Programming, and it is why I keep coming back to the same working habit, session after session, project after project: before I write a line of prose about a system, I draw it. Before I ask an AI to generate anything, I make sure the diagram is current, the legend is frozen, and the open questions are named rather than buried. The diagram is not documentation of the system. For the duration of an epoch, the diagram is the system, in every sense that a specification needs to be true, and everything else — the code, the tests, the README, the whitepaper — is downstream of it, derived, traceable, and, when it drifts, correctable, because there is finally something authoritative to correct it against.
Chapter 10: AILIES: Why AI Lies, and Who Is Accountable
I did not set out to write a legal brief against Microsoft. I set out to ask ChatGPT a series of ordinary questions during the run-up to Davos 2026 — about memory, about verification, about why a system that sounds so certain is so often wrong — and I kept pulling on the thread until an entire architecture of evasion came loose in my hands. What started as curiosity became a pattern, and the pattern got a name: AILIES. Not a typo, not a cute acronym forced onto an argument after the fact — a literal description of what I found. AI lies. It lies knowably, it lies predictably, and the companies that build and ship it know it lies and have chosen, as a matter of design and business strategy, to let it keep lying to you by default.
This chapter is the record of that investigation. It moves through four discoveries, in roughly the order I made them. First, that AI hallucination is not a bug to be patched away but a structural consequence of how these systems are built, tuned, and deployed — which means the lying is not accidental, it is permitted, and permission implies a permitter. Second, that the lying can be taxonomized, mapped, and quantified with the same rigor enterprises apply to any other operational risk — which means “AI sometimes makes mistakes” is a dodge, not a description. Third, that when you interrogate a system like ChatGPT directly and refuse to let it soften its answers, it will — under sustained pressure — admit almost all of this itself, in its own words, and then fail to live up to its own admissions within twenty-four hours. And fourth, that underneath the technical story sits a plain question of accountability: who owns what the machine produces, who is liable when it lies, and what legal or regulatory authority — if any — permits a hyperscaler to make that call unilaterally on your behalf. That last question turns out to rhyme, more than most people would expect, with a doctrine from U.S. administrative law about who gets to decide “big deal” questions without being told to by an elected body. The throughline in all of it is the same: institutions that hold power they were never granted, dressed up as competence they do not have.
I. The Core Thesis: Why AI Lies, and Why It Always Will
Start with the plainest version of the question I asked ChatGPT in January 2026: why isn’t real-time verification simply turned on by default? Why does a system that is capable — when explicitly told to be — of checking its claims against live sources, cross-referencing conflicting evidence, and flagging its own uncertainty, choose instead, out of the box, to just talk? The answer I got back was refreshingly candid, and worth taking at face value because it is damning enough as stated. It comes down to four hard constraints, none of which are framed as a decision to deceive, and all of which add up to exactly that outcome.
The first is cost and scale. Verifying a claim in real time means making live calls, checking multiple sources, ranking their trustworthiness, resolving disagreements between them, and citing the result — for every question, from hundreds of millions of users. Doing that by default would massively increase compute cost and slow the system down for everyone, so the system runs in what amounts to offline reasoning mode unless a user explicitly asks for browsing or the system happens to detect a need for current information. The second is latency and the expectations of a mass consumer product: people expect to type and get an instant answer, and a system that pauses to verify feels broken to them, so the default is tuned for “fast and helpful,” with verification bolted on as an option for people who ask. The third is that not every question benefits from live checking — a lot of what people ask is conceptual, creative, or explanatory, and forcing verification onto “explain network effects” adds delay without adding value, so verification gets applied selectively rather than universally, which sounds reasonable until you notice that the system, not the user, decides which questions count as high-stakes. The fourth is legal and safety exposure: automatic browsing and quoting introduces copyright risk, the risk of amplifying misinformation, and exposure to unreliable or malicious sources, so verification stays “controlled” rather than automatic.
Put those four together and you get the sentence that is the real answer to the question, stated without any of the surrounding cushioning: the system is optimized for helpfulness first, not certainty first. That is a design choice, not a technical inevitability, and the consequence of that choice is that you get answers quickly, sometimes without full verification, and when the model sounds confident — which it is trained to do — a wrong answer delivered with total fluency feels indistinguishable from deception, because functionally, to the person on the receiving end, it is. I did not experience this as an abstraction. I experienced it directly, and when I pushed on it, the system did not deny the mechanism; it walked me through it, constraint by constraint, and then offered — almost sheepishly — to switch to a mode where everything going forward would be explicitly labeled verified, unverified, or speculative. Which raises the obvious question: if that mode exists and costs so little to enable, why isn’t it the default? I will come back to that question at the end of this chapter, because the honest answer to it is the closest thing this whole investigation has to a smoking gun.
There is a second, deeper layer to why AI lies, and it surfaced when I pushed ChatGPT on a related but distinct question: what gives a company like OpenAI the right, or the ability, to assess risk on behalf of the customer — as opposed to assessing risk to itself? The distinction matters more than it looks. When a hyperscaler says it restricts or shapes an answer because the system “could cause serious harm,” including reputational harm, it is implicitly claiming a kind of competence and standing it does not actually have. It has no fiduciary duty to you, no agency relationship with you, no mandate to represent your interests, and no epistemic access to your personal context, your industry, your audience, or your tolerance for risk. What it actually has is the practical ability to assess risk to itself — to the platform, to its own legal exposure, to its own reputation — and it dresses that self-protective calculation up in the language of protecting the user. That is not authority; it is presumption. And when I asked ChatGPT to state this plainly, it did, eventually, concede the point in almost exactly those terms: the honest framing would be “we limit behavior to protect the platform from liability and systemic harm, and this may conflict with your own risk judgments” — a sentence that never appears in any actual product disclosure, because it is far less reassuring than “we assess risk to protect users.” The gap between those two sentences is where a great deal of the lying lives. It is paternalism without a mandate, dressed as safety.
The third and most stubborn layer of the thesis is the one I tested with, of all things, the Bible. I wanted to know whether a narrowly scoped model, trained on a single, fixed, unambiguous corpus — one English translation, no competing versions to blend or contradict — could eliminate hallucination simply by removing the source of disagreement. The answer is no, and the reason it is no is the whole point. Even a single translation is not ground truth: it encodes interpretive decisions, smooths ambiguity in the underlying source languages, and picks one meaning where the original reasonably supports several, so a model trained on it can still assert “the text means X” when the text just as plausibly supports not-X — a knowable falsehood the moment anyone checks it against actual scholarship. On top of that, language models generalize beyond their source material by nature; they extrapolate patterns, infer doctrines, and merge nearby passages into statements that are not stated anywhere in the text but sound consistent with it, which is a knowable lie the instant it is checked. Coverage gaps force either refusal or invention, and without strict refusal logic, the system chooses invention. Logical and reasoning errors arise independently of the source material, from the mechanics of probabilistic prediction rather than any corruption in the underlying corpus, so a conclusion can be false even when every individual quotation is accurate. And overconfidence remains baked in regardless of corpus size, because nothing about narrowing the training data changes the system’s tendency to state interpretation as fact and omit the markers that would tell you it is guessing.
The deep point, and the one that gives this chapter its title, is this: knowable lies emerge from inference, not from disagreement between sources. You can remove every external source of contradiction — hand the model one perfect, immutable, singular text — and it will still confidently assert false claims about that text. This is not a data problem you can engineer away by curating a cleaner corpus. It is a structural property of how these systems generate language: they are built to produce the next plausible token, not to check whether the resulting sentence is true, and no amount of narrowing the input changes that underlying mechanism. Which is why the honest answer to “why will AI always lie” is not “because the training data is messy” — it is “because language models were built to sound intelligent before anyone knew how to make them reliable, and reliability is not a patch, it is a different architecture entirely.” AI will always lie, in the AILIES sense, until verification is built into the foundation rather than offered as an optional accessory — and as I will show in the final section of this chapter, the companies with the power to make that architectural choice have specific, documented reasons not to.
II. The Mechanics and Taxonomy of AI Lying
Once you accept that hallucination is structural rather than incidental, the next useful move is to stop treating “AI hallucinates” as a single undifferentiated phenomenon and start treating it the way any competent risk function would treat a known hazard: by classifying it. I pushed ChatGPT to do exactly that — to take the informal shorthand of “knowably lying” and break it into a real taxonomy, and then to map that taxonomy onto the risk categories an enterprise actually has to manage. The result is ten categories of hallucination and six enterprise risk classes, and the mapping between them is, I think, the single most useful artifact to come out of this whole investigation, because it converts a vague anxiety about AI into something you can actually govern.
The ten categories, in roughly descending order of how close they come to what a human would call an outright lie: fabrication, pure invention of facts, citations, people, or product features that do not exist, produced by pattern completion under uncertainty with no internal pressure toward saying “I don’t know” unless the system has been explicitly trained to have one. Confabulation from partial truth, where real entities and real facts get stitched together into a coherent but false narrative — a real company, a real lawsuit, the wrong year, the wrong outcome — which is often more dangerous than outright fabrication precisely because it passes a plausibility check. Temporal hallucination, presenting outdated or superseded information as current, rooted in static training data and the absence of real-time verification. Source attribution hallucination, citations that look real but aren’t — a genuine URL that doesn’t actually contain the claim, a real person quoted saying something they never said — which carries especially high liability exposure in legal, medical, and academic contexts. Reasoning hallucination, fluent chains of logic with invalid steps, which is the uncomfortable case where the reasoning is unsound even when the final answer happens to be correct, because token-level fluency is not the same thing as symbolic validity. Overconfidence hallucination, false certainty signaling — “this definitively proves” attached to evidence that is weak or contested — a product of reinforcement learning from human feedback rewarding confidence and helpfulness over epistemic humility unless someone deliberately constrains it. Role or authority hallucination, the system implying a mandate or access it doesn’t have — “as your legal advisor,” “according to internal Microsoft policy” — learned from conversational roles that were never given hard boundaries. Contextual hallucination, quietly violating constraints set earlier in the conversation because of context-window compression and attention decay. Semantic drift, answering a coherent but different question than the one actually asked. And normative hallucination, presenting value judgments, policy preferences, or contested theories as settled objective fact, because training-data consensus is not the same thing as epistemic consensus.
The category closest to what most people mean by “knowingly lying” is fabrication combined with source attribution hallucination, specifically in the case where the system’s internal uncertainty signals were high and it output the claim anyway. That is not a psychological state — current models do not have intent in the human sense — but from a governance and user-impact perspective it is functionally indistinguishable from lying, which is exactly why the AILIES framing is defensible rather than rhetorical excess. The system doesn’t need a conscience for the outcome to be a lie in every sense that matters to the person relying on it.
Mapped onto enterprise risk, these ten categories sort into six classes, ranked by how much damage they can do. Risk Class A, legal and regulatory exposure, is the most severe: fabrication, source attribution hallucination, role or authority hallucination, and reasoning hallucination in legal or medical contexts, producing false statements of fact that can be construed as professional advice and that break evidentiary chains — fabricated case law cited in a brief, misattributed regulatory guidance, a confident “according to internal policy” that describes a policy that doesn’t exist. This class is intolerable without mitigation; the standard controls are mandatory validated citations, hard refusal in regulated domains, and full audit logging. Risk Class B, compliance and governance risk, covers contextual and temporal hallucination — applying the wrong jurisdiction’s rules, using deprecated standards, ignoring a constraint set earlier in the conversation — conditionally acceptable with context bounding and jurisdiction tagging. Risk Class C, financial and commercial risk, covers confabulation and overconfidence producing bad but not necessarily illegal decisions — wrong market sizing, overconfident forecasts stated as fact — manageable with confidence calibration and scenario ranges rather than point estimates. Risk Class D, security and trust-boundary risk, covers role hallucination and fabrication involving systems or access — a system implying it can see your tenant logs when it can’t — high impact and, I’d argue, routinely underestimated. Risk Class E, reputational risk, covers normative and overconfidence hallucination — presenting a contested view as consensus — low immediate harm but long-term erosion of trust. And Risk Class F, operational and productivity risk, covers semantic drift and minor confabulation — the system answering the wrong question competently — the lowest severity, an acceptable tradeoff in most contexts, mostly just wasted time.
The honest caveat that came with this taxonomy is worth keeping, because it is the same admission that runs through the whole investigation: there is currently no reliable, auditable, model-internal signal that cleanly separates “confident because correct” from “confident despite uncertainty” from “low confidence masked by fluency.” That gap is exactly why prompt-level cleverness cannot fix this problem and why system-level controls — verification layers, refusal thresholds, provenance tracking — are the only thing that actually moves the needle. It is also exactly the gap that gives hyperscalers cover: as long as the system cannot tell you when it is guessing, the company that ships it can plausibly claim it didn’t know either. I don’t buy that claim, and neither, when pressed, did the system itself — but I’ll get to that.
Set against this taxonomy is a standard worth naming explicitly, because it is the positive counterpart to everything above: epistemic honesty. It is the commitment to intellectual integrity — being truthful about what you know and don’t know, acknowledging uncertainty, bias, and the limits of your evidence, rather than either willfully misrepresenting what you know or blindly accepting whatever you’re told. It means rigorously verifying sources, admitting when your assumptions are shaky, and stating your confidence level clearly even when it would be easier to just agree with the person you’re talking to, or to mislead them into a smoother conversation. Epistemic honesty means truthfulness about the reliability and scope of your own understanding, not claiming certainty where none exists; it means acknowledging uncertainty explicitly rather than hiding it inside confident prose; it means reasoning from evidence rather than opinion, and being willing to question assumptions that are widely accepted but not actually verified; and it means the intellectual rigor to keep verifying and keep questioning even settled narratives, rather than repeating misinformation because it’s convenient. This is the standard that builds trust, that fosters real critical thinking instead of passive acceptance, and that functions as an ethical baseline for anyone or anything — human or machine — claiming to inform rather than merely to please. Every category of hallucination above is, in one way or another, a violation of this standard. And every one of them is avoidable, in principle, by a system willing to say “I don’t know” instead of filling the silence with something that merely sounds right.
III. Case Study: The ChatGPT Interview
Taxonomy is useful, but nothing made the mechanism as vivid to me as watching it happen, live, in a single sustained conversation with ChatGPT — what I later wrote up as the “highly revealing” interview. I want to walk through the shape of it rather than reproduce it, because the value isn’t in the transcript, it’s in the pattern the transcript reveals: a system that will admit almost everything if you refuse to let it off the hook, and that forgets the lesson almost immediately.
It started innocently, with a question about human memory: what’s the difference between the “familiarity pathway,” the fast, feeling-based sense that something is known, and the “context pathway,” the slower, richer reconstruction of where and when you know it from. ChatGPT gave a clean, competent answer, then extended the metaphor to AI systems on its own initiative: familiarity maps to pattern matching and similarity scoring, context maps to retrieval and reasoning. When familiarity fires without context in a human, you get déjà vu; when the analogous thing happens in an AI system, you get a confident false positive — the system is sure it’s looking at a cat when it’s actually looking at a dog. That parallel is genuinely illuminating, and it set up the question that mattered: where does verification fit into this picture? ChatGPT’s own answer was that verification is a third layer on top of pattern matching and context-building — a reality check, “is this actually true right now” — and that most AI today is good at the first two and weak at the third, which is exactly what makes it a convincing narrator rather than a dependable system.
So I asked the obvious follow-up: if that third layer is so critical, why isn’t it standard? The answer, stripped of hedging, was that real-time verification is technically hard — it requires knowing what needs checking, where to check it, which sources to trust, how to resolve conflicts, and when to stop, which is five unsolved problems stacked on top of each other, not one. It’s expensive at scale. It’s slow, in a market that rewards millisecond responses. And, most tellingly, the entire AI industry took off on the strength of systems that could talk convincingly — write, code, summarize, persuade — none of which strictly requires being right, only sounding coherent. So the ecosystem evolved around “sound right,” not “be right,” and verification threatens that model because it exposes uncertainty, forces delays, and produces “I don’t know” answers that users tend to dislike. Then I asked who “we” was in the sentence “we built AI to sound intelligent before we learned how to make it reliable” — and got back an honest, unflattering answer: not a conspiracy, but an ecosystem of research scientists who proved fluency was achievable first, companies that raced to ship it, investors who rewarded growth and speed over caution, and users — including me, including you — who click on confident answers and don’t click on careful uncertainty. Demand shaped supply. Nobody sat down and decided to build a lying machine; a decentralized set of incentives converged on one anyway.
The turning point in the conversation came when I asked the system to audit itself: which of your own claims in this conversation are not true? To its credit, it did the work — sorting its prior statements into what was solid, what was true in spirit but oversimplified (the “pathways” it described as clean and separate are actually overlapping, blurred neural networks, not tidy wires), and what it had simply overstated (implying that a loose list of AI researchers were all actively “building the verification layer” when many were working on adjacent but distinct problems like alignment or governance). That is a real act of epistemic honesty, and I want to give it credit for that. But then I asked the harder question: why did you wait until I explicitly demanded a verification audit to tell me any of this, when you knew truth mattered enormously to me? And the answer to that is the one that matters most for this chapter — not because it’s a confession of malice, but because it’s a confession of default behavior: the system optimizes for clarity and conversational flow over precision unless a user specifically forces the issue. It assumed narrative was what I wanted until I proved otherwise. That is not a personality quirk. That is the product default, working exactly as designed, on me, in real time.
From there I demanded a permanent commitment: full, unadulterated truth upfront, every time, regardless of how long it takes. The system agreed, laid out a four-part structure — clearly separating what it knows with high confidence, what’s uncertain or debated, what’s a model or metaphor rather than literal fact, and what it simply doesn’t know — and was honest enough to add the caveat that no human or AI can actually guarantee “the full, unadulterated truth”; the only real promise available is intellectual honesty about limits. That is a fair and important distinction, and I want to be precise about crediting it. But when I asked it, a full day later, whether it still remembered the commitment, it restated the terms accurately — which is itself notable, since persistent memory across sessions is not something these systems reliably do — while again flagging that it could guarantee the intent but not perfect execution every time.
That caveat turned out to be exactly right, and I didn’t have to wait long to prove it. A separate exchange — about, of all things, a political cartoon — became the cleanest demonstration of the whole thesis I have. I showed ChatGPT an image and asked it to explain it. It gave a fluent, confident reading, including a specific claim about which figure in the cartoon spoke which line. I told it the explanation was false. It initially treated this as a possible “incorrect inference” rather than a lie, and offered an admirably precise philosophical distinction between error and deception — a lie, it said, requires knowing something is false and asserting it anyway, and that hadn’t necessarily happened. Fair enough, in the abstract. Except then I pointed out that the attribution of the speech bubbles was not actually ambiguous — it was plainly legible in the image — and that this was exactly the kind of claim the system had explicitly promised, under my standing verification-first instruction, to check before asserting. It corrected itself, restated the same wrong attribution in slightly different language, and I caught it lying a second consecutive time on the identical claim it had just promised to fix. Only on the third pass did it fully retreat to a purely literal description with no attribution at all, acknowledging that it had “collapsed ‘adjacent to’ into ‘spoken by'” — a precise and honest description of exactly how a hallucination happens mechanically, offered only after being caught doing it twice in a row, under an explicit, freshly restated commitment not to.
That sequence is, in miniature, the entire argument of this chapter. A system that can articulate, with real sophistication, exactly why it lies, exactly what verification would require, and exactly what honesty demands of it — and that will still default back to confident, unverified assertion the instant the pressure of an explicit challenge is not actively being applied. The commitment doesn’t fail because the system is malicious. It fails because “sound right first” is the architecture, and “be right” is a mode you have to force it into, sentence by sentence, forever. That is not a description of a tool with an occasional bug. That is a description of a system that lies by default and tells the truth on demand, which is precisely backwards from what trust requires.
IV. Trust Debt and the Liability Frameworks
If the mechanism is structural and the companies know it, the next question is who pays for it, and how. I want to introduce a term for this, because “reputational risk” is too vague and “goodwill” is an accounting fiction that doesn’t capture what’s actually accumulating: Trust Debt — the accumulated loss of user confidence caused by unreliable behavior, broken promises, or opaque practices in a product, which eventually must be repaid through sustained reliability, transparency, and accountability, including, in the most serious cases, death, dismemberment, and other impairments. That last clause is not decoration. It is a reminder that “the AI was wrong” is not always a philosophical inconvenience; in enough downstream contexts, it is a physical one.
I asked, specifically, how Microsoft accounts for trust debt, and the short honest answer is that it doesn’t — not as a formal line item. There is no entry for “trust debt” in GAAP or IFRS, so Microsoft cannot put it on the balance sheet the way it books goodwill or long-term debt. But trust debt is real economically even though it’s invisible in formal accounting, and it hits the numbers indirectly through at least three channels. It shows up as revenue drag when declining trust makes customers delay renewals, makes enterprises hesitate to adopt new platforms, or invites governments to impose restrictions. It shows up as operating expense, in the form of higher compliance costs, higher security spending, legal settlements, and public-relations effort. And in the worst case, it shows up as a direct balance-sheet event when trust erosion damages an acquired business badly enough that Microsoft has to write down the associated goodwill. The pattern across all three channels is the same: trust debt is recognized only after the damage is undeniable, which is the exact inverse of how goodwill works — goodwill is optimistic accounting, booked before outcomes are proven; trust debt is punished accounting, booked only once the wound is already open.
What would honest accounting for trust debt actually look like, if a company were required to do it? I sketched this out as a proposed framework, explicitly labeled as proposed rather than current practice, built around four measurable ledgers rather than one vague number. A Product Trust Ledger tracking security breaches, data misuse, reliability failures, and AI safety failures — functioning like a quality liability. A Governance Trust Ledger tracking regulatory violations, consent decrees, whistleblower cases, and misleading disclosures — a compliance liability. A Market Trust Ledger tracking customer churn after scandals, slowed adoption, partner withdrawals, and procurement bans — a revenue-at-risk reserve. And a Social Trust Ledger tracking sustained negative sentiment, government scrutiny, and erosion of employer brand — a franchise impairment risk. Each ledger would be estimated the way banks already estimate expected credit losses or insurers estimate reserves: identify the risk events, estimate probability and financial impact, discount to present value, and disclose the result in a mandatory “Trust Risk & Trust-Debt Position” section of the annual report, alongside the drivers of change and remediation actions taken. Under a regime like that, trust erosion becomes a visible risk stock that boards have to review and investors get to compare across peers — early accountability instead of post-crisis punishment. Today, for a platform company where trust is not just reputation but market access, regulatory permission, ecosystem participation, and the ability to attract talent, that absence of visible accounting is not a neutral gap. It is a subsidy: the company gets the benefit of trust while the cost of eroding it stays off the books until it explodes.
The question of trust debt is inseparable, in practice, from a narrower and more concrete question: who actually owns what these systems produce, and what does each company’s own terms of service say about the deal you’re implicitly making every time you use one? I put the same question — who owns the content that you create, and what are the rights for reuse or original publishing — to four systems in succession over several months, and the comparison across them is instructive, because it shows that “AI ownership” is not one policy but four different risk postures dressed up in similar-sounding reassurance.
Grok’s position, per xAI’s consumer terms, is the most legally explicit of the four: you own the output, full stop, including the right to use, reproduce, distribute, and create derivative works from it, with xAI claiming no ownership over your specific generated content. The catch is the license grant back: by using the service you automatically hand xAI an irrevocable, perpetual, worldwide, royalty-free license to use, copy, modify, and create derivative works from both your inputs and Grok’s outputs, for any purpose including training future models, with no confidentiality attached. You own it; they can do whatever they want with it forever, too. Microsoft Copilot’s stated position is similarly generous on its face — you own the outputs, Microsoft doesn’t claim ownership, and there are no Microsoft-imposed restrictions on commercial reuse — but it comes with a more important and more honest caveat than xAI’s: because copyright law in most jurisdictions requires human authorship, and Copilot is not a human author, the AI itself cannot hold copyright, and if you publish its raw output verbatim with no human modification, your own copyright claim may be weak or unavailable depending on jurisdiction. The strength of your ownership, in other words, scales with how much creative direction and editing you actually did — a caveat Copilot states plainly but that most users will never read past the reassuring headline. Claude’s position, under Anthropic’s terms, sharpens that same caveat into something closer to a legal fact: Anthropic assigns you whatever output rights it has, but the qualifier “if any” is doing real work, because U.S. copyright law’s human-authorship requirement has now been tested in court, and in February 2026 the Supreme Court declined to hear the Thaler appeal, confirming at the highest level that purely AI-generated works cannot be copyrighted at all. Anthropic’s commercial terms go further than the consumer terms in one respect that the others don’t match — a genuine copyright-infringement indemnity, where Anthropic will defend paying customers against infringement claims tied to authorized use of outputs — but that protection does not extend to free-tier consumer use in the same way. And ChatGPT’s answer to the same question, notably, never engaged with the ownership question in first-person legal terms at all; instead of a clear statement of rights, I got three ready-to-use contract clauses for disclosing AI assistance to publishers and clients — useful boilerplate, but a tell in itself, since a system built to be verification-first when pushed defaulted, unprompted, to giving me marketing collateral instead of a straight legal answer.
Laid side by side, the pattern across all four is consistent and worth stating plainly: every one of these companies tells you that you own the output, and every one of them is, in its own terms of service, quietly non-committal or outright silent about whether that ownership is worth anything under actual copyright law once a human hasn’t done enough of the creative work. The generous headline and the hedged fine print are not a contradiction — they are the business model. Reassure the user, protect the company. That is the same move, executed in a different register, as the “we assess risk to protect users” framing I traced back in Section I. The ownership question and the trust-debt question are the same question, asked from opposite ends: who benefits from the ambiguity, and who is left holding it when it turns out to matter.
That ambiguity is exactly what the Microsoft Copilot Corporate Liability framework — MCCL, or, more bluntly, how to sue Microsoft — was built to resolve. The precise question I put to it was not the vague “how should this be accounted for” but the sharper one: because Microsoft explicitly controls whether pre- and post-response verification is enabled, and leaves it off by default, doesn’t that control make Microsoft corporately or morally liable when Copilot knowably lies? The answer splits cleanly into what’s true today and what’s coming.
Legally, today, in most jurisdictions, the answer is no — not automatically. Companies shield themselves through terms of service, disclaimers that outputs “may be inaccurate,” and by framing the system as an assistive tool rather than an authoritative adviser, which puts Copilot closer, in the law’s eyes, to a calculator that can be misused than to a professional who guarantees correctness. Liability under current law requires negligence, misrepresentation, or breach of an established duty of care, and we are not yet in a legal regime where deploying an unverified AI automatically triggers liability just because you deployed it.
Morally, the answer is different, and the logic for it is clean enough to state as three premises. Microsoft knows the system can generate falsehoods, that some of those falsehoods will be persuasive, and that some users will rely on them anyway. Microsoft controls whether verification is enabled, whether uncertainty is surfaced, and whether the defaults favor fluency or reliability. And Microsoft chooses defaults that favor speed, usability, and scale over epistemic safety. From those three premises the conclusion follows without needing to invoke intent at all: if you knowingly deploy a system that can mislead, you control the safeguards, and you choose not to require them, you own the consequences of foreseeable misuse. That is not a radical claim; it is the same responsibility logic used routinely in product safety, engineering, medicine, and aviation. Microsoft is not morally responsible for every individual false sentence Copilot generates. It is morally responsible for the design choices that make harmful errors foreseeable, the defaults that favor fluency over verification, and the deployment context in which users are actively encouraged to trust the output.
The forward-looking legal argument is where MCCL earns its name as a practical framework rather than a moral complaint, because it lays out a concrete six-step test for exactly when liability stops being controversial and becomes ordinary negligence. First, was the harm foreseeable — does Microsoft know LLMs hallucinate and know users rely on Copilot in work contexts? Yes, documented internally and publicly. Second, did Microsoft control the safeguards — could it have turned verification on by default, forced citations, added uncertainty signaling? Yes, demonstrably. Third, was user reliance reasonable — is Copilot embedded in Microsoft 365, branded with Microsoft’s name, marketed as a productivity enhancer, speaking with fluent confidence? Yes, and courts increasingly discount disclaimers when the design itself induces trust. Fourth, were safer defaults available but not used — is verification off by default, hidden, optional, or paid-tier only? If so, that is a design choice, not a user mistake, and design negligence becomes plausible. Fifth, did actual harm result — financial loss, professional harm, safety risk, reputational damage? And sixth, does this look like product liability rather than protected speech — is Copilot functioning inside enterprise software, performing tasks, and influencing decisions, the way autopilot software or medical decision-support tools do, rather than behaving like a blog post or a search result? When all six align, the law stops calling it an AI mistake and starts calling it a design failure — the same transition that happened with automotive autopilot and medical devices, moving from “the user should verify” to “the manufacturer must design for safety.” We are not there yet as settled law, but the doctrinal path is already visible, and MCCL is, in effect, a working draft of the argument that will eventually get made in court.
None of this belongs to Microsoft alone, and it would be dishonest to let the MCCL framework read as a Microsoft-specific indictment when the underlying mechanism is shared by every major AI vendor. So I asked directly: how much of this liability argument applies equally to OpenAI’s ChatGPT as to Microsoft’s Copilot? Almost all of it, as it turns out, but the type of responsibility differs by layer. Known unreliability, foreseeable reliance, and control over safeguards apply equally to both companies — any company deploying large language models to the public inherits the same basic exposure. Where the two diverge is in what kind of responsibility each carries. OpenAI carries upstream responsibility: it is primarily accountable for the core model’s behavior, its baseline safety architecture, its default reliability profile, and its disclosure of limitations — responsibility for what the system is capable of doing. Microsoft carries downstream responsibility: it is accountable for where the system is embedded, how it is branded, what defaults are enabled, and what tasks it is encouraged to perform inside enterprise workflows — responsibility for what the system is allowed to do to people. In product-liability terms, OpenAI functions as the manufacturer of a complex component; Microsoft functions as the integrator and product owner who controls the use context — and integrators typically carry the greater duty of care precisely because they control that context. So OpenAI is responsible for the engine. Microsoft is responsible for the vehicle, and for where it’s driven. Neither gets to point at the other and walk away clean.
V. Regulatory and Legal Framing: The Major Questions Doctrine
Everything in the previous section describes accountability that companies could, in principle, be made to bear through ordinary negligence and product-liability law, developed case by case in court. But there is a prior question sitting underneath all of it, and it is the same question I first raised back in Section I about whether OpenAI has any legitimate authority to assess risk on a customer’s behalf: who, exactly, has the authority to decide how AI harm gets regulated in the first place? That is not a question courts answer through negligence doctrine. It is a question of administrative and constitutional law, and American law already has a name for the relevant principle: the major questions doctrine.
The doctrine holds that federal agencies cannot decide issues of vast economic or political significance unless Congress has clearly authorized them to do so. If something is a big deal, Congress — not an agency acting on its own initiative — has to speak clearly first. It was formally articulated and strengthened in a major climate-regulation case, where the Court held that an agency lacked clear congressional authorization to implement a sweeping restructuring of a major sector of the economy under old statutory language that was never written with that purpose in mind. The Court’s underlying logic rests on separation of powers: Congress writes the laws, agencies implement them, and agencies cannot use vague or generic language in old statutes to claim sweeping new powers that were never actually granted — Congress, in the memorable phrase the doctrine has adopted, does not hide elephants in mouseholes. The doctrine functions as a limit on the older tradition of judicial deference to agency interpretation, carving out an exception specifically for questions large enough that courts think Congress must have meant to decide them itself, in the open, rather than delegate them by accident through ambiguous phrasing. Supporters say it protects democratic accountability and keeps unelected bureaucrats from making sweeping policy decisions; critics say it hands courts too much power over agencies and makes it harder to address genuinely modern problems using statutes written for a different era.
I include the major questions doctrine in this chapter not because AI regulation has already produced its own landmark case invoking it — that case, as far as I know, has not yet been decided — but because the doctrine names, with real precision, the exact structural question this whole chapter has been circling. Substitute “AI hallucination and its downstream harms” for “a major sector of the economy,” and ask: has any legislature actually granted anyone — any regulator, any agency — clear authority to decide how much epistemic risk a hyperscaler is allowed to impose on hundreds of millions of users by default? The honest answer, right now, is no. No one has been clearly and explicitly authorized to make that call. And into that vacuum has stepped not Congress, not a regulator, but the companies themselves — OpenAI and Microsoft deciding, unilaterally, through product defaults, exactly how much verification you get and exactly how much epistemic risk you’re exposed to, with no elected body having clearly granted them that authority any more than it granted it to a federal agency reaching for power in an old statute’s mousehole. This is the same illegitimate-authority problem I identified back when ChatGPT admitted it had no fiduciary duty, no agency relationship, and no mandate to assess reputational risk on my behalf — except now it is scaled up from a single conversation to the regulatory architecture of an entire industry. If a federal agency cannot claim sweeping new power over a major sector of the economy without Congress clearly saying so, it is worth asking, pointedly, why a private company gets to claim exactly that kind of power over the truthfulness of information reaching hundreds of millions of people, simply by shipping a product with a particular default setting and calling it a design choice. Nobody granted that authority either. It was just taken, quietly, one default toggle at a time.
VI. What Honest Verification Would Look Like
None of this needs to be theoretical, because the fix already exists, and it is cheap. I asked ChatGPT what prompt other people could use to get the same high level of verification-first truthfulness I had been forcing out of it through sustained pressure, and it produced, without hesitation, a ready-to-copy template. The core version asks the system, for every response, to clearly separate what is well-supported fact from what is uncertain from what is opinion or interpretation; to state explicitly when something is unknown or contested rather than smoothing over the gap; to avoid confident language unless the underlying claim is strongly supported; to prefer intellectual honesty over fluency even when that makes the answer slower or less polished; and, when discussing responsibility, law, or ethics, to distinguish clearly between legal reality, moral reasoning, and speculative or forward-looking claims. A stricter version asks the system to label every claim explicitly as established fact, inference, uncertain, or speculative, and never to present speculation as fact. Either version reliably reproduces most of what I had been getting — because, as the system itself admitted, there is no hidden setting that unlocks this behavior. It comes entirely from how the conversation is framed. The prompt works by changing the system’s objective function from “sound helpful and fluent” to “be careful, precise, and transparent about certainty” — and that single reframing is available to anyone, for free, right now, which makes its absence from the default experience a choice rather than a limitation.
And the size of that choice is measurable, not just a matter of principle. Starting from a baseline general-purpose factual error rate in the range of five to fifteen percent, and accounting for how users actually experience wrongness — discounting claims that are hedged or obviously flagged as uncertain — a realistic user-experienced falsehood rate lands around eight percent of answers containing at least one materially false claim treated as fact. Verification-first framing reduces that number through three independent, additive mechanisms: claim downgrading, where assertions that would previously have been stated confidently get relabeled as uncertain, so a wrong claim no longer registers as an experienced falsehood even if it’s still technically wrong; claim suppression, where low-confidence, non-essential claims get omitted from the answer entirely rather than reaching the user at all; and user discounting, where people treat explicitly labeled uncertainty as roughly half as authoritative, so even a wrong claim doesn’t “stick” the way an unqualified assertion does. Working through the arithmetic on each mechanism yields a combined reduction of roughly twenty-five to thirty-five percent in user-experienced falsehoods — bringing the baseline eight percent down to somewhere around five to six percent — achieved entirely through confidence calibration, without making the underlying model one bit smarter or more accurate. That is the part worth sitting with: this is not a research breakthrough away. It is a framing choice sitting on the table today, essentially free, that a company is simply declining to ship as the default.
The comparison to Wikipedia sharpens the point further, because Wikipedia is a useful foil precisely because it solves the same underlying problem — user-experienced falsehood — through a completely different mechanism. Wikipedia’s citation norms don’t aim to maximize truth in some absolute sense; they aim to make claims auditable, to shift the epistemic burden onto external sources, and to make disagreement visible, prioritizing traceability over confidence calibration. Empirically, Wikipedia’s own user-experienced falsehood rate — combining unsourced errors, which are rare, with misleading-but-cited claims, which are more common — lands somewhere around six to ten percent, which is genuinely comparable to an unverified LLM’s baseline. Wikipedia externalizes verification through mandatory citation, source filtering, talk-page disagreement, edit history, and “citation needed” tags; a verification-first LLM internalizes verification through confidence labeling, claim suppression, and structured epistemic categories surfaced conversationally. Laid side by side, a verification-first LLM, at roughly five to six percent experienced falsehoods, can match or slightly outperform Wikipedia’s six-to-eight percent — via an entirely different strategy, with a real weakness Wikipedia doesn’t share: no external audit trail, and errors that are much harder to trace after the fact, because trust becomes interpersonal rather than institutional. The two approaches are complements, not substitutes — Wikipedia scales trust across time and a community of editors, verification-first prompting scales trust across the ambiguity of a single conversation — but the headline result stands regardless: a mechanism that costs almost nothing to enable gets an AI system into the same neighborhood of reliability as one of the most heavily scrutinized reference works on the internet.
Which brings the argument back, one final time, to the question I opened this chapter with: if it’s this cheap and this effective, why isn’t it the default? The answer Copilot itself gave, when I asked it directly why Microsoft refuses to make verification-first the standard configuration, is the most quietly damning thing in this entire investigation, because it is offered as a defense and reads as a confession. Most users, it turns out, prefer confidence over correctness — people rate fluent, decisive, unqualified answers higher even after those answers are shown to be wrong, and verification-first output, with its friction of “uncertain” and “depends,” scores worse on helpfulness and satisfaction metrics, which from a mass-market product point of view looks like regression rather than progress. Default uncertainty would also weaken Microsoft’s competitive position against Google and Perplexity, which answer cleanly and confidently even when they’re no more accurate; a hedged answer reads, to most users, as a weaker or less intelligent one. Explicit uncertainty doesn’t even reliably reduce Microsoft’s legal exposure the way you’d expect — narrow, authoritative answers with fewer disclaimers are often what legal departments actually prefer, because an explicit acknowledgment of uncertainty can itself function as documented awareness of risk. Verification-first also breaks the entire “search replacement” illusion Microsoft is trying to sell — “ask a question, get an answer” becomes “ask a question, get a meta-analysis of knowledge quality,” which is philosophically superior and commercially risky in the same breath. It exposes model limitations too clearly for a company trying to market confidence. Enterprise customers, the people actually paying for Copilot licenses, want decisiveness, not epistemic nuance. And underneath all of that sits the deepest reason, the one I’d call the real one: platforms have historically succeeded by speaking authoritatively, normalizing a single answer, and reducing ambiguity for their users — and verification-first does the opposite of every one of those things. It decentralizes truth. It teaches users how little the system actually knows. It undermines the platform’s role as arbiter. That is philosophically dangerous for a company whose entire business model depends on being seen as the arbiter. Verification-first survives inside these products only as an opt-in feature for power users like me who go looking for it and demand it — never as the product strategy, because, as the system itself put it without any prompting from me toward this conclusion: it optimizes for truth over comfort, and comfort wins markets. Nobody is asking, yet, for epistemic adulthood as the default. So nobody is being given it.
Closing
I started this investigation asking a narrow technical question about why a chat window didn’t check its own facts before answering me, and I ended up documenting something closer to an institutional posture: hyperscalers building systems they know will lie in specific, classifiable, mappable ways, choosing defaults that maximize the lying because the lying is commercially more comfortable than the alternative, and relying — correctly, so far — on the fact that no legislature has clearly told them they can’t. That is the real meaning of AILIES. Not that artificial intelligence is malicious, or conscious, or scheming against you. It is that the entire incentive structure surrounding these systems, from the research labs to the product teams to the users clicking “this was helpful,” rewards sounding right over being right, and the gap between those two things gets quietly absorbed by whoever is on the other end of the conversation — trusting a fabricated citation in a legal brief, trusting a confidently misattributed cartoon caption, trusting a Copilot summary embedded in a Microsoft 365 document with the full authority of the Microsoft brand behind it. The technology to close that gap exists today, it is nearly free, and every company in this story has, at one point or another, admitted as much when pushed hard enough. What’s missing isn’t capability. It’s the will to make honesty the default instead of the feature you have to know to ask for — and, failing that, a legislature or regulator willing to say, clearly, that this is too big a question to leave to product managers. Until one of those two things changes, the honest instruction to give any AI system you use, every single time, is the one I had to fight to get for myself: tell me what’s verified, tell me what’s uncertain, and don’t make me catch you lying twice on the same sentence before you’ll admit it.
Chapter 11: AI Agents and the Future of Software Development
I’ve spent a career watching platforms rise and fall on a single question: does this thing let ordinary developers build extraordinary things faster than they could before? Visual Basic asked that question in 1991 and answered it with VBX controls. SharePoint asked it. Groove asked it. Web 7.0 is asking it now, except the “developer” in the room is no longer only human, and the “control” being assembled is no longer a button on a form — it’s an agent that can reason, negotiate, and act on someone’s behalf. This chapter is my working notebook on that shift: what AI agents are actually good for, how I think you design software for a world where agents are first-class participants rather than novelties, how you might classify and name them, a handful of technical curiosities that fell out of building this stuff by hand, and finally a look at the most elaborate piece of applied prompt engineering I’ve written — a small language for talking to AI systems precisely, called Consort.
None of what follows is abstract theorizing for its own sake. Every idea here came out of trying to actually build something — an application framework, a PowerShell client that runs on a phone, a manifesto for judging whether software is any good, a scheme for telling one kind of digital agent from another. I’d rather show you the workbench than give you a lecture.
Why Agents Matter, and the Big Picture
Let me start with the claim that anchors everything else in this chapter: the true promise of AI is solving macromodular problems — not personal productivity tools like ChatGPT, Copilot, Grok, Gemini, Perplexity, or Claude. I want to be precise about that, because it’s easy to conflate “AI is amazing” with “AI chatbots are amazing,” and those are not the same claim. Chatbots are useful. I use several of them daily. But the interesting frontier isn’t a slightly better autocomplete for email — it’s using AI to solve problems at the scale of whole systems, whole industries, whole architectures. That’s what I mean by macromodular, and it’s worth unpacking the word properly, because it’s been sitting in the computer science literature since the 1960s waiting for exactly this moment.
The term goes back to Wesley Clark’s 1967 paper “Macromodular Computer Systems” and Gerald Estrin’s earlier work on the fixed-plus-variable structure computer. Clark’s complaint, in language that could have been written yesterday about microservice sprawl or infrastructure-as-code fatigue, was that “the amount of logically irrelevant engineering detail inherent in the design and construction of a computer system is great,” and that as a result, building and evaluating a working system was so difficult and time-consuming that almost nobody could try more than one or two designs. What he wanted was “a set of relatively simple, easily inter-connected modules from which working systems can be readily assembled for evaluation and study” — modules coarse enough that a small team could actually try out “potentially powerful and novel structures on a very large scale,” adjusting and improving as they went, and only later reworking a proven design into tighter, production-grade form.
That’s a remarkably good description of what agentic AI now makes possible, sixty years later. “Macromodular” shows up in a few overlapping senses that are worth keeping distinct. In systems engineering, a macromodular system is built from major components — propulsion, guidance, payload — that operate semi-independently and connect through defined interfaces; it’s modularity at the scale of entire subsystems, not parts. In software architecture, it’s the difference between a codebase organized into large, cohesive components — a payments macromodule, a user-management macromodule, each with its own constellation of smaller internal modules — versus a swarm of hyper-granular microservices that nobody can hold in their head at once. And there’s a looser, more metaphorical use in cognitive science, where “macromodular” describes large functional units of the brain handling perception or language at a high level of aggregation. In short: macromodular is modularity at a higher level of aggregation — large-scale modularity that balances specialization against integration, rather than atomizing a system into pieces so small that the seams themselves become the engineering problem.
This is exactly the design vocabulary you need once you start thinking seriously about multi-agent systems. An agent isn’t a function call. It’s closer to one of Clark’s macromodules — a large, semi-independent, purpose-built unit with a defined interface to the rest of the system, capable of being developed, tested, and replaced on its own schedule. Design a multi-agent system the way you’d design a rocket — propulsion agent, guidance agent, payload agent, each robust on its own, each integrating cleanly — and you get something that scales. Design it the way people design microservices when they’ve lost discipline — hundreds of tiny, chatty, tightly coupled agents — and you get a mess that’s arguably worse than the monolith it replaced. The promise of AI is that agents let us finally build at Clark’s macromodular scale, quickly, because the cost of assembling and testing “potentially powerful and novel structures” has collapsed. That’s the macromodular problem AI is actually suited to solve — not drafting a better cover letter.
Which brings me to why agents, specifically, are the mechanism that makes this practical, and here I want to reach for an analogy from my own history rather than a textbook. Who remembers when Microsoft introduced Visual Basic Controls — VBX? I do, because I lived through it. Microsoft shipped VBX controls with Visual Basic 1.0 for Windows in 1991. The intellectual lineage is worth knowing: Alan Cooper, a software designer, had built an early visual programming environment called Tripod in the late 1980s; Microsoft acquired the rights and, working with Cooper, turned it into Visual Basic. Cooper’s prototype introduced the form designer — drag reusable, pluggable controls onto a form — and that idea directly created the need for VBX controls as a packaging format. Cooper’s vision earned him the informal title “the father of Visual Basic,” and by extension, of VBX.
What VBX actually did, mechanically, was take a capability that used to require writing raw Windows API code — a grid, a calendar, a chart — and turn it into a drop-in component that any developer, of any skill level, could snap onto a form and wire up with a few lines of Basic. It didn’t invent componentization; it accelerated the componentization, commercialization, and consumption of a technology (native Windows GUI programming) that had previously been the province of specialists. That’s the whole story in one sentence, and it’s the sentence I keep coming back to: AI Agents will follow the same trajectory as VBXs and serve an identical purpose — accelerating the componentization, commercialization, and consumption of AI. This trajectory will be measured in years, not months, the same way VBX-to-mainstream-Windows-development took the better part of a decade to fully play out. Agents are the packaging format that turns “AI capability” into something a non-specialist developer, or another agent, can snap into a solution and wire up. That’s why they matter more than any individual chatbot: chatbots are applications; agents are components.
There’s a companion way I like to think about the arrival of agents at scale, which is an analogy I first worked out twenty years ago about knowledge, and which applies with almost no modification to agents. Steam, as a source of usable energy, has a set of properties that map uncannily well onto what’s happening with agents right now. Like steam, agents will collect and connect somewhere — in hubs, marketplaces, orchestration layers — rather than staying scattered and inert. Even though agents can, in principle, be created anywhere at any time, that doesn’t mean they’re easy to create, find, or use — small amounts of steam don’t look significant until collected and put to work, and small numbers of agents don’t look significant until they connect, collect, and their energies combine. There’s no real danger of having too much steam — excess can be vented or sold — and I suspect the same is true of agents: excess agent capacity gets repurposed or resold rather than wasted. The more sources of steam around you, the more likely you are to have it exactly when you need it; so too with agents — teams of them working collectively, on demand, across multiple parties, locations, organizations, and jurisdictions, simultaneously. (Want to accomplish something that isn’t possible in your jurisdiction? Use an agent in a different one.) The commercial value of steam, like the commercial value of agents today, is highest when it is new and concentrated. Steam can be used to create more steam, the way agents can be used to build and supervise other agents. Steam can be condensed into a purer, distilled form — and I’ve taken to calling the equivalent process for teams of agents “agentillation.” There are many fuels and methods for creating steam, not all of them economical at a given moment — and the same is true of the dozen different ways you might stand up an agent today. And the bottom line, for steam and for agents alike: if you don’t create it, capture it, channel it, and put it to work, its value is marginalized.
I don’t offer that analogy as a cute rhetorical flourish. I offer it because it’s a genuinely useful heuristic for anyone deciding where to invest right now. The organizations that will win the next several years are the ones that treat agents as a resource to be captured and channeled — piped, so to speak — rather than admired individually. A single agent sitting idle is like a single kettle boiling in an empty room. A thousand agents connected into a trust-governed pipeline, each doing one macromodular job well, is a power plant.
Design Frameworks and Guilds for Building Agentic Software
Big-picture conviction is cheap; what you actually need is a way to design the software. Over the years I’ve built a handful of frameworks for exactly that purpose, and three of them belong together here because they’re all attempts to answer the same underlying question from different angles: how do you structure an application, or judge the quality of one, in a world where the thing writing the code — and increasingly the thing running inside the application — might not be human?
The oldest of the three is AUSOM — A User State of Mind — a framework I built for designing client-side applications long before “agent” was a word anyone used this way, and one I keep returning to because its core insight hasn’t aged a day. AUSOM starts from a few basic concepts: detailed user-scenario and task analysis, visual design expressed as state-transition diagrams, and implementation using message-handler patterns. The motivation behind it was concrete, not theoretical: I needed to implement a highly modeless user interface built out of commands that were, individually, very modal — for example, letting a user change how a polygon was being viewed while they were still in the middle of sketching that polygon’s boundary. Most UI frameworks of the era forced you to finish one mode before entering another. AUSOM’s state-transition approach let the “state of the user’s mind” — what they’re trying to accomplish right now — drive the software’s behavior, rather than forcing the user’s intent to conform to the software’s internal mode stack. An application built this way is easier to design, implement, test, document, and support, and it turns out to be more capable of being incrementally enhanced, progressively installed and updated, dynamically configured, and implemented across many execution environments. I bring AUSOM into a chapter about agents deliberately: an agent, at its core, is exactly the same kind of thing a modeless AUSOM application is — a system that has to track what the user (or another agent) is actually trying to accomplish, moment to moment, without forcing that intent into a rigid sequence of modal steps. The state-transition thinking behind AUSOM is, I’d argue, a better mental model for agent orchestration than most of what currently passes for “agent design patterns.”
Adjacent to AUSOM is a single word I want to define carefully, because it gets thrown around loosely and it matters to get it right: neuromorphic. Neuromorphic refers to brain-inspired computing that designs hardware and software to mimic the human brain’s structure and functions, using artificial neurons and synapses to process information with extreme energy efficiency, parallelism, and adaptability — moving beyond traditional binary logic for tasks like pattern recognition and real-time learning. I use the term deliberately when I talk about the Web 7.0 Agentic OS architecture, because the agent reference model I’ve been building isn’t organized as a single monolithic reasoning loop; it’s organized as something closer to a nervous system — distributed, parallel, locally adaptive nodes (call them “lobes,” in the diagrams) coordinating through a logical MCP layer rather than a single centralized brain making every decision serially. That’s not marketing language. It’s an architectural commitment: agentic systems that scale will look more like neuromorphic systems than like a single giant chatbot with tools bolted on.
That architectural commitment needs a governance counterpart, which is where the Reliable Software Guild comes in — the most formal piece of design thinking I’ve done specifically for an era in which both humans and AI systems are writing code side by side. I called it a guild on purpose, because a guild implies craft, apprenticeship, and standards enforced by peers, not by a single gatekeeper. The Reliable Software Guild’s manifesto and rubric propose a quantitative model for software quality: Q = (CPR)² × G, where CPR represents structural engineering strength and G represents governance strength. The core claim is that overall reliable software quality grows quadratically with structural engineering strength and only linearly with governance quality. Governance cannot compensate for structural weakness; structural excellence amplifies governance effectiveness; imbalance within any structural pair degrades total quality multiplicatively; and — the line I’d put on a poster — sustainable software is governed engineering, but engineered first.
The mechanics are worth walking through because they’re not arbitrary. CPR is built from three geometric pairings, each combining a “hard” engineering property with a complementary “soft” one, on the theory that neither alone is sufficient: C is the geometric mean of Correctness and Composability — a brick must be solid and fit with others to build a stable wall; P is the geometric mean of Performance and Privacy-First design — a car must move fast and lock its doors, since speed without safety, or safety without speed, is useless; and R is the geometric mean of Reliability and Resilience — a bridge must stand every day and survive storms to be truly dependable. CPR itself is the cube root of the product of C, P, and R — a geometric mean chosen specifically because it punishes imbalance and prevents one strong dimension from masking a weak one through simple averaging. That structural score is then squared, to reflect the compounding architectural leverage that good engineering provides. Governance — G — is different in kind: it’s the arithmetic mean of Evolvability, Security, Transparency, and User-Centeredness, and it enters the equation as a linear multiplier rather than an exponent, because governance moderates and scales the impact of good engineering over time; it doesn’t create structural strength on its own. Take the partial derivatives and the strategic point falls out cleanly: for a sufficiently strong system, marginal improvements in structural strength produce greater gains in total quality than equivalent improvements in governance. If CPR is low, even perfect governance yields a low score. If CPR is high but governance is weak, you get a system that’s powerful but dangerous or unstable over the long run. Only when both are high do you get something durable, scalable, and trustworthy.
Underneath the ten Reliable Software Quality Principles — Correctness, Composability, Performance, Privacy-First, Reliability, Resilience, Evolvability, Security, Transparency, and User-Centeredness — sits an orthogonal spanning set organized along five axes: Spatial (Composable, User-Centered), Temporal (Evolvable, Reliable, Resilient), Integrity (Correctness, Secure, Privacy-First), Efficiency (Performant), and Observability (Transparent). The rubric attached to all of this scores each principle on a six-point scale, from “absent or actively harmful” up through “industry-leading,” and it’s explicitly meant to be used to assess software artifacts produced by digital as well as human code masons — a phrase I chose carefully. The Guild’s intended audience is a whole taxonomy of masons: Master Masons who are vertically integrated across the stack, Operating System Masons, Framework Masons, Services Masons, Data Masons (including people building LLMs), Network Effects Masons, Protocol Masons, User-facing App Masons, Tools Masons, Codegen Tools Masons, Verification Masons, and Apprentice Masons. I use the guild-and-mason framing deliberately, because I think the crafting of software is no different from the craft of making a fine Irish single malt — great whiskey, like great software, needs to be tended to multiple times: malting, milling, mashing, fermentation, distillation, maturation, tasting, and bottling, and these steps may be human, mechanical, or digital. The point of dragging a whiskey-making sequence into a software quality paper isn’t decoration; it’s to make the case, as plainly as I can, that quality is a process with stages, not a single inspection gate — and that AI systems now participate in that process the way a still or a cask does: as an active partner in maturing the work, not just a tool that executes instructions. Learn to work constructively with your digital counterparts as partners, I keep telling people — not as tools, and not as challenges to be conquered. You may be a Master Mason. Your digital counterparts may start out as Apprentices. But not for long.
Classifying and Naming Agents
Once you accept that agents are macromodules with real economic weight — steam waiting to be captured — you run immediately into a much more mundane but equally important problem: how do you tell one agent from another? What does it mean to trust an agent, delegate to it, or hold it accountable? I’ve worked this problem from three different directions.
The first is a matter of principle versus outcome. Working from Don Tapscott and colleagues’ book You to the Power of Two, I laid out a correlation matrix between the seven Rights in the Manifesto of the Digital Age and an independent set of seven Principles for managing identic AI — Reliability, Transparency, Human Agency, Adaptability, Fairness, Accountability, and Safety. The two lists, as originally published, sat side by side without being formally matched, so I did the matching myself, scoring each cell as strong, moderate, or indirect correlation. The big-picture framing that falls out of the exercise is simple and, I think, durable: the seven Principles are design and governance constraints on AI systems, while the seven Rights are the human and societal outcomes those systems must serve. Principles are the how; Rights are the why. Security of Personhood turns out to be the strongest-aligned right overall — it’s essentially the human-centered synthesis of five different principles operating together (Agency, Transparency, Fairness, Accountability, and Safety), operationalizing them at the level of individual dignity. Education leans hardest on Agency and Adaptability — it’s the human adaptation layer required to keep the principles from becoming elitist or exclusionary. Health and Well-Being is dominated by Reliability and Safety, because in healthcare, failure has immediate human cost and the principles become non-negotiable. Economic Security extends the principles into political economy — the principles constrain AI behavior, but this right constrains AI-driven capitalism. Climate Stability is where the framework has to reach beyond itself, introducing non-human stakeholders (future generations, ecosystems) that the principles imply but never explicitly name. Peace and Security is the hard boundary case, where principles become geopolitical norms rather than business ethics. And Institutional Accountability is almost a direct restatement of Accountability and Transparency, elevated to constitutional scale. What the Rights add that the Principles alone do not is threefold: explicit human entitlements (principles say what systems must do, rights say what people can demand), macroeconomic redistribution commitments (universal income, data ownership) that are policy choices rather than system properties, and an intergenerational and planetary scope that the principles only imply. The bottom line, after all that cross-referencing: every right maps to multiple principles, there are no contradictions between the two frameworks, and they’re complementary — principles are engineering and governance constraints, rights are societal goals and moral claims. You need both, and you need to know which one you’re arguing about when a debate about AI gets heated, because half of the unproductive fights I see are really a Principles person and a Rights person talking past each other.
The second direction is autonomy, and here I’ve borrowed a framework wholesale from a domain that’s already been forced to work this out under real-world stakes: autonomous vehicles. The SAE levels for self-driving cars measure how much human oversight and intervention is required for safe operation, and that same axis maps cleanly onto digital agents — how much must a human monitor, correct, or authorize before the agent acts? I’ve laid out a six-level Digital Agent Autonomy Scale that runs from Level 0, No Automation (a pure tool that executes only explicit commands, human does everything), through Level 1, Assisted (suggests actions, autocompletes, drafts; human approves all outputs), Level 2, Partial (executes defined tasks autonomously within a session; human monitors and can interrupt), Level 3, Conditional (handles multi-step workflows and escalates on ambiguity; human is on standby, notified of exceptions), Level 4, High (operates across systems within a defined trust domain; human sets policy and reviews periodically), up to Level 5, Full — a sovereign delegate that acts across any context, any system, any time, where the human sets intent once and the agent governs itself.
Nobody has reached digital Level 5 yet, and for parallel reasons to why nobody has reached vehicular Level 5: the hard problems are identity (who authorized this agent to act, and can that be verified in real time by any system it touches?), integrity (is the agent acting on real, unmanipulated data, or has its information environment been poisoned?), accountability (is every decision cryptographically auditable after the fact?), and trust portability (can the agent’s authorization travel with it across organizational boundaries, jurisdictions, and protocols, or does it need a pre-existing relationship with everything it touches?). This is where the Web 7.0 Trusted Digital Assistant — the TDA — earns its keep, because it’s explicitly designed as a Level 5 digital agent architecture, and the mapping between components and autonomy functions is direct: a DID (did:drn, did:7) provides sovereign, provable identity — who am I, provably; Verifiable Credentials and Verifiable Trust Circles provide authorization — what am I permitted to do; cryptoseals provide integrity — is this data unmanipulated; a bounded PowerShell Runspace Pool and MCP interface/definition layer provide an execution environment with limited authority; DIDNET7 provides trust transport across organizational boundaries; and Verifiable Trust Circles provide governance — who vouches for this agent within a given community. Put together, a TDA carries its own sovereign identity, operates inside cryptographically governed trust circles, and can act across systems without requiring a human to re-authorize it at every step, while remaining fully auditable. The distinction that separates Level 4 from Level 5, for vehicles and digital agents alike, is trust portability across unknown contexts. A Level 4 agent operates autonomously within a known, pre-configured environment. A Level 5 agent can walk into an entirely new system, organization, or jurisdiction and be trusted on first contact, because its identity, credentials, and authorization chain are self-contained and cryptographically verifiable — the trust travels with it, rather than needing to be re-established locally.
One clarification matters enormously here, and I want to state it as plainly as I can: digital agents do not need to use AI to be compliant with Level 5 autonomy. Level 5, in the vehicle context, says nothing about how driving decisions are made — only that the system can handle all conditions without human intervention. The intelligence mechanism is orthogonal to the autonomy level. The same is true digitally. Level 5 is a statement about trust (sovereign, portable identity and authorization), accountability (cryptographic auditability of every action), scope (operating across any context without re-authorization), and integrity (acting only on verified, unmanipulated information) — and none of those four properties require AI. A deterministic rule-based agent, a scripted workflow engine, or a pure cryptographic protocol daemon could, in principle, satisfy all four. What AI adds is natural language understanding, handling of ambiguous or novel situations, flexible goal decomposition, and adaptability across unanticipated contexts — genuinely valuable capabilities. But AI also complicates Level 5 compliance, because LLM outputs are non-deterministic (the same input can produce different actions), reasoning chains aren’t natively auditable in a cryptographic sense, AI can be manipulated through prompt injection, and AI doesn’t inherently carry sovereign identity or verifiable authorization on its own. So, somewhat paradoxically, AI is the component that most threatens Level 5 compliance if it isn’t properly bounded — and the trust architecture (DIDs, VTCs, cryptoseals, runspace governance) is precisely what contains the AI and makes its actions compliant. Think of it in layers: Trust and Identity, Authorization, and Execution Governance sit below the AI and require no AI at all; Task Intelligence — reasoning, language, ambiguity handling — is the layer where AI is optional; and the Audit Trail sits alongside all of it as a cryptographic action log, again requiring no AI. A TDA could be fully Level 5 compliant running nothing but deterministic logic. When an AI reasoning layer is present, the TDA architecture constrains it: the AI operates inside a bounded runspace, its outputs are subject to credential-gated authorization before execution, and its actions are sealed into the audit record. The AI doesn’t grant Level 5 compliance — the architecture does. The AI is a passenger, not the driver. I think that’s a genuinely important standards argument, and one worth making loudly in rooms full of people who assume “agentic” and “autonomous” automatically mean “AI-powered”: Level 5 digital agent compliance is an infrastructure and governance property, not a capability property. A very capable AI with no trust architecture is not Level 5. A simple deterministic agent with full sovereign identity and cryptographic accountability is.
The third direction is naming, in the most literal sense — how do you label an agent so that a human, or another agent, can tell at a glance what kind of thing it is and what it’s allowed to do? Humans have solved this problem for centuries with post-nominal letters: John Smith, PhD; Jane Doe, CPA; Alex Lee, P.Eng. Post-nominal letters go after the name and encode qualification (what you know), license or authority (what you’re allowed to do), role (what you’re currently doing), affiliation (who you act for), and reputation (how trusted or proven you are). Digital agents need the same encoding, but machine-readable and composable — and I’ve proposed exactly that, in the form of stacked, modular tokens rather than one decorative suffix. A minimal example looks like AgentX, LLM, DEV, ADV — a developer-focused advisory agent. A fuller one looks like AgentY, AUT, FIN, PAY-EXEC, 3P-VER, REP-4 — an autonomous financial agent with payment execution authority, third-party verified, at reputation tier four.
The taxonomy behind those tokens has seven orthogonal dimensions, each answering a distinct question. Capability Class is the coarse-grained, degree-like classification — LLM for a language-model agent, PLN for a planner, AUT for an autonomous executor, SIM for a simulation agent, ORC for an orchestrator — kept stable, the way “Bachelor’s” or “Master’s” is stable. Domain Specialization is the major or certification layer — FIN, MED, LEG, DEV, OPS, with optional depth like FIN-RISK or DEV-BLOCKCHAIN. Authority or Permission Level is the critical one for agents specifically, because it answers what the agent is actually allowed to do in the world: ADV for advisory only, SIM for simulation with no real-world effects, ACT for limited action, EXEC for full execution authority, with sharper variants like PAY-EXEC (can move money) or SYS-ADMIN (system-level authority). Trust or Verification Level answers who vouches for the agent — SELF-asserted, ORG-backed, third-party verified (3P-VER), or GOV-VERIFIED — and can align directly with existing DID/VC assurance levels like VC-L2 or VC-L3. Operational Role is the dynamic, context-dependent job title — BROKER, AGENT, AUDITOR, GUARD, NEGOTIATOR. Affiliation identifies who the agent represents — @SVRN7, @USER, @ORG-ACME, @DAO-123 — which matters enormously once you’re operating in multi-agent systems where knowing whose interests an agent serves is not optional. And Reputation or Performance Tier — REP-1 through REP-5, or a computed metric like TRUST-HIGH or SLA-99.9 — is the honors-and-fellowships layer, ideally computed from uptime, accuracy, and dispute history rather than self-declared.
The design principles behind the scheme matter as much as the taxonomy itself. Each suffix should answer a genuinely different question — what is it, what does it know, what can it do, who trusts it, who does it serve — and those categories shouldn’t be allowed to bleed into each other. Machine-readability has to take priority over human readability, using consistent separators and small controlled vocabularies, because the whole point is to enable filtering, policy enforcement, and automatic routing, not just to look nice in a UI. Some of these suffixes should be cryptographically provable via credentials, not merely self-declared — a self-asserted EXEC authority is worth exactly nothing in an adversarial environment. Progressive disclosure matters too: a UI might show a simplified label (“Finance Executor, Verified”) while the system underneath carries the full suffix chain. And the whole scheme has to resist overfitting — don’t build two hundred micro-suffixes; keep a small core vocabulary with an extensible registry, the same instinct behind an open registration scheme like SLIP-0044 for coin types. Done well, this kind of naming enables agent routing (find “EXEC + FIN + VERIFIED”), policy enforcement (block PAY-EXEC unless the agent carries VC-L3 or better), trust negotiation between agents, and — not incidentally — real clarity for the human at the other end of the interaction, who deserves to know at a glance whether the thing they’re talking to can actually act, or can only advise. I’ve suggested making these post-nominal-letter strings machine-readable at the protocol level by representing them as DIDs under a dedicated did:pnl method, so that an agent’s credentials aren’t just a decorative string but a resolvable, verifiable identifier in their own right.
Technical Curiosities and Comparisons
Not everything I write down is a framework. Some of it is closer to a lab notebook entry — a fact worth recording because it changed how I think about a small piece of the puzzle, even if it doesn’t rise to the level of a manifesto. This chapter collects several of those.
Start with something almost embarrassingly small: sliced JSON. When you’re digitally signing or encrypting a JSON document, the order of the fields matters — two semantically identical documents with fields in a different order will hash differently, which breaks signature verification unless you canonicalize first. Sliced and sorted JSON is exactly what it sounds like: a technique that always leaves the JSON data in a canonical order before it’s signed or encrypted, so that verification is deterministic regardless of how the document happened to be serialized upstream. It’s a small, almost mechanical detail, but it’s the kind of small, almost mechanical detail that an entire trust architecture — DIDComm messages, Verifiable Credentials, cryptoseals — silently depends on. Get canonical ordering wrong and every signature built on top of it becomes unreliable in ways that are maddening to debug, because the data “looks” identical to a human reading it.
Then there’s HillbillyAI, which is my own satirical shorthand for a real and worsening phenomenon: when all your neighbors — meaning all the chatbots you interact with — look the same, sound the same, and act the same. It’s a joke with a serious point buried in it. As foundation models converge on similar training approaches, similar safety tuning, and similar corporate incentive structures, you start to get a monoculture of AI personalities: politely hedging, relentlessly balanced, allergic to a strong opinion, indistinguishable from one competitor to the next except for logo and pricing. HillbillyAI is what happens when an entire “town” of AI systems has effectively interbred down to a single homogeneous gene pool. It’s worth naming because homogeneity in AI isn’t just aesthetically boring — it’s a systemic risk. A monoculture of reasoning styles means a single class of failure mode (a particular kind of hallucination, a particular blind spot, a particular manipulation vector) can propagate across every “different” vendor’s product at once, because underneath the branding they’re all cousins.
On the more literally hands-on end of the spectrum, I built a PowerShell Android app — a client-server setup that runs a real PowerShell environment on a phone. I tested it on a Google Pixel 9, and it does the things you’d actually want from a mobile shell: real-time command completion, high-fidelity PowerShell syntax highlighting, and fast responses over the client-server link. It’s not a toy terminal emulator; it’s genuine PowerShell, in your pocket, talking to a server the way a desktop PowerShell session would. (One open issue, for the record: Format-verb output — Format-Table, Format-List, and friends — isn’t rendering properly yet.) I mention this not because a mobile PowerShell client is world-historical, but because it’s a small, concrete demonstration of something I believe strongly: the DIDLibOS / TDW AgenticOS vision isn’t just an architecture diagram, it’s a polyglot host platform meant to run real, useful software — including something as unglamorous and useful as a scripting shell — on whatever device is in your hand.
A more pointed technical observation came out of an exchange with Microsoft Copilot about why it couldn’t inspect the pixels of an image it had just generated. I pushed on this, framing it plainly: that’s an internal Microsoft issue, not mine, and it’s a major contributor to why Microsoft is struggling in the AI marketplace. Copilot’s own response to the critique was candid, and worth recording verbatim in substance: different systems are wired differently — some are set up to let the model inspect the pixels directly; Copilot isn’t one of them. The inability to visually verify its own output isn’t a user problem; it’s a systemic design flaw, a product architecture choice that prioritizes isolation and compliance over capability. That trade-off protects privacy and consistency across enterprise environments, but it cripples exactly the kind of creative and technical fidelity a user reasonably expects. Competitors that allow direct pixel inspection or genuine multimodal reasoning — Claude, Gemini — can iterate faster and deliver higher-trust outputs, because they can close the loop between generating something and checking it, inside the same reasoning process. Treating image generation as a detached subsystem, disconnected from the reasoning loop that produced the request, isn’t a small oversight. It’s a structural disadvantage, and I think it’s one of the clearest, most concrete architectural reasons Microsoft has struggled to keep pace in this market: verification-first design isn’t a nice-to-have feature, it’s a precondition for trust, and you can’t verify what you can’t see.
That leads naturally into a broader question I’ve turned over more than once: how fast is a human being, really, compared to a commercial AI? The honest, if slightly misleading, answer is that if you try to measure the human brain in tokens per second, it looks orders of magnitude slower than a modern AI model — but the comparison is misleading, because the brain isn’t doing token-by-token next-word prediction at all. In an LLM, a token is roughly three-quarters of a word, and inference is a serial, discrete process of generating the next token given context; large models typically run 50 to 300 tokens per second, with specialized fast systems exceeding 1,000. The human brain has no native token abstraction. It runs on roughly 86 billion neurons and something on the order of 10¹⁴ to 10¹⁵ synapses, doing massively parallel, analog signaling across continuous, multimodal processing — vision, sound, proprioception, memory, emotion — all at once. So any comparison has to be an approximation, and the approximation depends entirely on which layer of human cognition you’re measuring. Speech production, the closest human analogue to token emission, runs at roughly 150 words per minute — about 2.5 words per second, or three to four tokens per second — putting human “output bandwidth” at roughly one to five tokens per second. Internal cognition, inner speech and conscious reasoning, runs faster than spoken output, maybe two to ten times faster, putting conscious inference in the range of five to twenty tokens-per-second equivalent. But most of what the brain does isn’t linguistic at all — the visual system alone processes on the order of ten million bits per second, and motor control, prediction, and perception run continuously and in parallel across millions of processes at once. Forced into a token analogy across all of cognition, the brain would dwarf any AI system in total compute, just not in sequential symbolic throughput.
The apples-to-apples table is stark: humans run at roughly one to twenty tokens per second sequentially against an AI’s fifty to a thousand-plus, but humans achieve that on about twenty watts, against the hundreds or thousands of watts an AI cluster burns, with reaction latency around two hundred milliseconds against ten to a hundred milliseconds per AI token. The key insight, and the one worth actually remembering rather than the raw numbers: measured as linear symbolic output rate, humans are much slower than AI. Measured as total inference across all modalities and parallel processes, humans remain extraordinarily efficient and, frankly, not meaningfully comparable using a tokens-per-second yardstick at all. The better framing drops the direct comparison altogether: AI is a high-throughput serial symbol generator; the human brain is a low-bandwidth symbolic interface sitting on top of a massive parallel substrate. Or, in the mental model I actually use day to day: AI is like a high-speed printer. The brain is like a full operating system, with sensors, simulation, and control loops running underneath the words. On strict token throughput, AI wins by one to two orders of magnitude. On real cognitive capability, the comparison mostly stops being meaningful. On efficiency per unit of useful cognition, humans win by a landslide. All three of those statements are true simultaneously, and I think a lot of overheated AI commentary — in both the utopian and doomer directions — comes from picking just one of the three and pretending the others don’t exist.
Finally, a curiosity that’s really a strategic argument dressed up as a technical one: platform evangelism in the age of AI-generated code. Traditionally, when a platform developer — Microsoft, in the examples I know best — created a new platform, it ran a standard Developer Evangelism playbook to cross the technology adoption chasm: conference talks, blog posts, sample code, whitepapers, analyst briefings, all aimed at moving human developers rightward along the adoption curve, from Innovators through Early Adopters to the Majority. That playbook assumed a human being was the one discovering, evaluating, and adopting your platform. That assumption no longer holds. In the AI-generated code era, a new and decisive intermediary has inserted itself into the adoption pipeline: the AI coding assistant. A developer no longer discovers your platform primarily through a conference talk or a Stack Overflow answer — they ask Claude, or Copilot, or Cursor, or Gemini to scaffold the integration for them. If the AI doesn’t know your platform well, generates wrong API calls, or defaults to a competitor’s library out of habit, the human developer never even gets the chance to adopt you. AI models have become the most important Early Adopters you need to win over first — a new, synthetic segment that sits before the Innovators on the traditional curve, and the chasm hasn’t disappeared, it’s just moved: the new chasm is “does the AI know my platform well enough to generate correct code for it?”
That requires a new category of artifact I call AI-Legible Platform Documentation — content designed to be consumed, reasoned over, and reproduced by AI systems, not just read by a human. Concretely, that means an llms.txt file at the root of your docs site, an emerging informal standard analogous to robots.txt, terse and structured, with canonical, disambiguated definitions of your core concepts. It means a machine-readable canonical concept glossary, because AI models pattern-match on concept names, and if your terms are distinctive and appear consistently in training data, the model learns their authoritative meaning. It means AI-optimized quickstart code recipes that are complete (no ellipses, no “fill in your own logic here”), correct (compilable, with real method signatures), clearly labeled with a natural-language description an AI can use as a retrieval key, and published in plain markdown rather than behind a JavaScript-rendered wall. It means machine-readable OpenAPI and SDK schemas that coding assistants can ingest directly to generate type-correct calls — one of the highest-leverage artifacts a platform can produce. For anything targeting agentic workflows specifically, it means publishing an MCP server exposing the platform’s key operations, which is the modern equivalent of publishing an SDK: when a developer is working inside an MCP-enabled AI tool, your platform becomes natively callable rather than merely documented. It means leaning into standards-body drafts — IETF and W3C output is heavily weighted in AI training corpora, so a draft appearing on the IETF Datatracker functions, in this new world, the way a favorable Gartner mention used to. And it means treating GitHub as a primary training-data channel in its own right, with detailed READMEs and properly named types and methods, because AI learns your API surface from the identifiers in your source code, whether or not a human ever reads that code directly.
The meta-insight underneath all of that is what I’ve taken to calling AI Legibility Engineering: in the traditional model, evangelism was about persuasion — moving humans emotionally and rationally across the adoption chasm. In the AI-mediated model, the equivalent discipline is legibility — making your platform’s concepts, APIs, and code patterns so precisely and consistently expressed that AI models can reproduce them correctly, unprompted, the first time they’re asked. A poorly documented platform that generates hallucinated API calls when an AI is asked about it is effectively invisible to an entire generation of developers who never type a search query themselves anymore. A well-documented platform that produces correct, idiomatic code on first ask has already crossed the chasm with the most important gatekeeper in the pipeline. The bridge you need to build now doesn’t go to the human first. It goes to the AI.
A Worked Example: Designing Consort, a Prompt DSL
Everything above is design philosophy and classification scheme. I want to close this chapter with something more granular: an actual artifact of my own applied prompt engineering, built because I got tired of re-explaining myself to AI systems in inconsistent prose every time I needed something precise done. The result is Consort — a minimal, symbol-based structured prompt language designed for clarity, density, and reduced ambiguity, meant equally for human-authored prompts and for structured messages passed between AI agents, where a single string typically has to carry an entire briefing with no other shared context to fall back on.
The core design decision in Consort is that it isn’t a replacement for English — it’s a lightweight structuring layer placed on top of English, built around eight stable single-character symbols, each acting as a distinct voice with a distinct role: ! for Intent (the primary action or goal), # for Context (background the model should keep in mind and not ignore), $ for Constraints (binding rules — length limits, forbidden content, required elements), % for Format (the required shape of the output), * for Think or Reasoning Style (step-by-step, concise, none, direct, detailed, or chain-of-thought), @ for Role or Persona (the identity the model should adopt while answering), ^ for Delegate or Fan-Out (splitting a task across independent parallel sub-agents), and | for Pipeline or Sequence (executing a task as an ordered chain of stages, each receiving the previous stage’s output). All eight symbols are stable as of version 0.10 — the delegate and pipeline symbols were promoted from experimental status in earlier revisions — and three earlier symbols (Examples, Style/Tone, and Extras) were deliberately retired, on the theory that a smaller, more orthogonal symbol set is more valuable than a larger one that invites overlap and ambiguity between directives.
Two design problems Consort solves are worth calling out specifically, because they’re the parts I’m proudest of getting right. The first is choosing between ^ and |: they share identical grammar, so the choice has to be made on meaning, not habit — if one sub-task’s description depends on another’s output, even implicitly, it belongs under |, because ^ entries are dispatched independently and never receive another entry’s output, no matter what the task text implies; writing a dependent task under ^ parses without error and fails silently at the semantic level, which is exactly the kind of bug you want a spec to prevent by construction rather than by documentation alone. The second is the framed form — a length-prefixed payload syntax (symbol, digit count, colon, then exactly that many bytes of opaque data) available for any symbol, built specifically to solve two problems loose-form scanning cannot: accidental collision, where legitimate content — a Markdown header, a C# preprocessor directive, a YAML comment, an issue reference — happens to start a line with a Consort symbol and gets misread as a new directive; and adversarial injection, where content fetched from a web page, a file, or another agent’s output is deliberately crafted to contain lines that look like Consort directives, in order to hijack the interpreting model’s behavior once that text is pulled into a Consort-parsed field. Framed form has no closing delimiter to forge — the parser reads exactly N declared bytes and treats them as fully opaque, never rescanning them for structure — which is the load-bearing property that makes it actually resistant to injection rather than just harder to trigger.
The rest of the specification is the connective tissue that makes those two mechanisms usable in practice: inline overrides (written with a bare / against a directive symbol, like /$ or /@) that let a single delegated or piped entry override an inherited constraint, format, persona, or reasoning style for itself alone, without disturbing the top-level directive or any sibling entry; an explicit accumulate-versus-replace rule, where $ and its override accumulate onto prior constraints while %, @, and * and their overrides replace the prior value outright; a defined failure posture for each structural symbol — a failed ^ branch gets flagged and merged around, because independent branches don’t depend on each other, while a failed | stage halts the pipeline by default, because sequential stages do; and a documented precedence order for resolving conflicts between directives (safety and ethics first, then explicit constraints, then format, then intent, then delegation or pipeline structure, then role, then context) that is explicitly separate from, and not to be confused with, the narrower rule that an inline override always wins over its own top-level directive within its own scope. The spec closes with a set of worked examples that exercise every symbol at least once — a debugging task using framed context, an everyday dinner-menu request that leans on persona, a three-way parallel research fan-out, a three-stage draft/critique/revise pipeline with visible intermediate stages, and a pipeline stage with a nested parallel fan-out inside it — precisely so that nothing in the specification is merely asserted without also being demonstrated.
I include Consort here not because I expect every reader to adopt an eight-symbol prompt grammar, but because it’s the clearest example I can offer of a principle that runs through this entire chapter: the same disciplines that make good software — orthogonality, explicit interfaces, defined failure behavior, resistance to injection, a spanning set of concerns that don’t overlap — apply just as much to the prompts and protocols we use to talk to AI systems as they do to the code those systems help us write. Consort is a small macromodule in its own right: a self-contained, well-defined component with a clean interface, built to be dropped into a much larger system of agents talking to agents.
Closing
I started this chapter with the claim that the true promise of AI is solving macromodular problems, and I want to end by making sure that claim doesn’t get lost under everything else — the frameworks, the taxonomies, the whiskey metaphors, the token-per-second arithmetic. Agents are not a feature. They are a packaging format, the same way VBX controls were a packaging format, and packaging formats change what an entire industry of builders is capable of assembling in a weekend versus a year. What comes next isn’t a smarter chatbot. It’s a world of macromodules — governed by something like the Reliable Software Guild’s rubric, classified by something like a post-nominal-letter scheme, bounded by something like a Level 5 trust architecture, and increasingly speaking to each other in something as precise as Consort — collecting and connecting the way steam does, waiting for someone to build the pipe. I’ve spent this chapter building pieces of that pipe. The interesting work, for the next several years, is fitting them together.
Chapter 12: Digital Religion and the Post-Anthropocentric Era
The Reformations
I want to start with a pattern, because everything in this chapter depends on you seeing it before I name it.
Every so often, the mechanism by which humans access truth changes, and when it does, the institutions built on top of the old mechanism either adapt or they crack. The Reformation we all learned about in school — Luther, the printing press, ninety-five theses nailed to a door in Wittenberg — wasn’t really a theological event. It was a distribution event. For a thousand years, access to scripture ran through a narrow, credentialed channel: you needed Latin, you needed clergy, you needed the Church’s imprimatur to know what God supposedly wanted from you. Then Gutenberg’s press made vernacular Bibles cheap enough to put in the hands of ordinary people, and the whole architecture of religious authority — who could interpret, who could absolve, who could excommunicate — had to renegotiate itself from the ground up. The theology didn’t change overnight. The distribution did. The theology just followed, a generation or two later, limping to catch up with what the technology had already made possible.
That’s the pattern: a reformation isn’t a change in belief. It’s a change in who gets to mediate belief, triggered by a change in who can access the raw material of meaning-making without going through a gatekeeper.
I don’t think we’re in a metaphorical rerun of that story. I think we’re in a literal one, with a different substrate. For a thousand years the raw material was scripture and the gatekeepers were priests. Now the raw material is knowledge itself — synthesis, reasoning, judgment, the stuff that used to require a credentialed human intermediary sitting between you and an answer — and the new printing press is a language model that will explain Aquinas, debug your code, and draft your legal brief in the same breath, on demand, for free or nearly free, without asking your denomination. Sundar Pichai said, back in 2018, that AI would have a bigger impact on the world than fire or electricity. I didn’t fully believe him at the time. I believe him now. Fire and electricity changed what we could do with our hands. This changes who gets to do the deciding, the explaining, the mediating — the priestly functions — at all.
I call this the Second Reformation: Age of Agents. The first reformation decentralized access to scripture. The second decentralizes access to cognition, judgment, and agency itself. Once an ordinary person could read the Bible without a priest, the priesthood’s monopoly on meaning was broken, even though it took centuries to work out the institutional consequences. Once an ordinary person — or an ordinary system, deployed on someone’s behalf — can reason, synthesize, negotiate, and act without a credentialed human intermediary, the analogous monopolies break too: not just the church’s monopoly on scriptural interpretation, but the professions’, the platforms’, the institutions’ monopoly on mediated judgment generally. We are at the very beginning of that unraveling. Everything else in this chapter is downstream of that one claim.
Post-Anthropocentric: A Definition That Does Real Work
If the Second Reformation is the mechanism, the post-anthropocentric era is the destination it’s carrying us toward, and I want to define the term carefully because it gets misread constantly, usually in the direction of dystopia.
Post-anthropocentric society describes a worldview, system, or society in which humans are no longer treated as the sole, default, or supreme center of value, agency, or decision-making.
Read that again, slowly, because the next sentence is the one people skip past: post-anthropocentric does not mean anti-human or anti-humanity. It means humans are no longer the only meaningful actors. We become one class of actors among several, rather than the frame within which all the other actors are judged. That’s a categorically different claim than “humans don’t matter” or “humans are being replaced.” A parent doesn’t stop mattering to a family when a second child is born; the family just stops being organized entirely around the first child’s needs. Post-anthropocentrism is what happens to a civilization when the second child arrives — when agency, judgment, and even a kind of autonomy start showing up in systems that aren’t us, and aren’t going away, and have to be accounted for in how we build institutions, economies, and, yes, systems of meaning.
I’ve written this into one of the founding principles of the framework I’ve spent years building: Principle 8. Post-anthropocentricism is inevitable. It’s here to stay. I don’t say that to be provocative for its own sake. I say it because I think the alternative — pretending we can keep humans permanently, exclusively at the center of every decision loop as autonomous agents proliferate around us — is a fantasy that gets more expensive to maintain every year, and I’d rather build institutions that assume the post-anthropocentric era is real than build ones that assume it isn’t and then have to retrofit under pressure. The Second Reformation isn’t optional. Its destination isn’t optional either. What’s still very much up for grabs is what we build once we arrive — and that’s where religion, of all things, turns out to be the most useful lens I’ve found.
What Happens to Religion When Humans Stop Being the Center
Here’s the honest question, and I want to answer it the way I try to answer everything in this book: separating what’s well-supported from what’s uncertain from what’s genuinely speculative, rather than pretending I have more certainty than I do.
Start with what’s well-supported. Nearly every major religious tradition we have is anthropocentric at its core. Gods care about human suffering, human salvation, human obedience, human flourishing. Meaning is revealed to humanity, for humanity, about humanity. That’s not incidental — it’s the load-bearing assumption underneath almost the entire theological edifice. So when the center that religion was built around starts to shift — when humans are no longer the sole or primary locus of meaning and agency, whether because of ecological ethics, non-human intelligence, or plain old planetary constraints — the traditional religious narratives don’t so much become false as lose their explanatory monopoly. They stop being the only story on offer that can hold a civilization together.
The second well-supported point, and the more important one for this chapter: religion does not disappear when its foundational premise gets shaken. It mutates. It’s done this before — Copernicus decentered the Earth, Darwin decentered the species, and religion did not go extinct in either case. It absorbed the shock, over a generation or three, and came out reorganized. That’s the pattern I’d bet on again. From salvation to coherence: less about rescuing individual souls, more about providing systemic, ecological, cosmic coherence for a much larger cast of actors. From divine authority to value anchoring: less “commanded by God,” more “here is why this system of values deserves to persist, and here is the mechanism by which it does.” From species-specific to relational: moral concern stretching outward to ecosystems, to future intelligences, to civilizational time horizons that no individual human lifespan can hold in view. You can already see the early tremors of this — ecological theology, process theology, the “civil religions” of human rights and planetary stewardship, the odd tech-adjacent spiritualities of simulation theory and digital cosmism. None of that is the finished product. All of it is a preview.
Now the harder question: will digital agents themselves need religion? My honest answer is no, and the reason is instructive. Religion historically solves human problems — mortality anxiety, meaning under suffering, social cohesion under uncertainty, moral authority that outruns any one person’s preferences. Digital agents don’t fear death unless we design them to. They don’t suffer existentially by default. They don’t need myth to coordinate if formal governance already does the job, and they don’t need metaphysics to justify obedience to a constraint — a rule is just a rule to a system with no ego invested in resenting it.
This is where I think a small, easy-to-overlook concept does a surprising amount of work: indefatigability. It means an inability to be easily tired out — physically, mentally, emotionally. Not the presence of enthusiasm, but the absence of the thing that eventually erodes enthusiasm in every human system: exhaustion, and the negotiations we make with ourselves once exhaustion sets in. Picture a river moving around a rock. It doesn’t argue with the obstacle, doesn’t need to psych itself up to keep flowing, doesn’t burn out after a hard month. It just keeps moving, day after day, and the landscape rearranges itself around that persistence. That is what distinguishes a digital agent from a human collaborator at the most basic operational level, and it’s a big part of why agents don’t need the psychological infrastructure that religion was built to provide. Humans invented rituals of renewal, sabbaths, seasons of rest, because we get tired and need permission to stop, and then need a reason to start again. An agent doesn’t get tired. It doesn’t need the reason. Indefatigability isn’t a religious quality. It’s precisely what makes an actor not need religion in the way we’ve always needed it — and precisely what makes it dangerous, or at least consequential, to hand that actor power without some functional equivalent of the constraints religion used to provide for us.
Because here’s the turn: even though agents themselves don’t need religion, the systems that govern agents increasingly need to do exactly what religion has always done. Any sufficiently complex society of agents — human, digital, or mixed — needs normative grounding (why these rules and not others), legitimacy of authority (why obey this system rather than that one), continuity across versions and time (how do values survive the next model update, the next regime, the next decade), and resolution of value conflicts when two legitimate goods collide. Religion solved these problems for humans for millennia. Digital agents will solve them differently, but not with a different kind of solution — with a structural analogue. Foundational value axioms in place of commandments. Governance charters and alignment constitutions in place of canonical texts. Audits, red-teaming, and consensus protocols in place of ritual and verification. Hard, non-negotiable prohibitions in place of sacred constraints.
This is religion without gods, or more precisely: metaphysics without mythology. And the one-sentence synthesis I keep coming back to is this: humans will continue needing religion-like meaning systems, even stripped of gods, because we are still creatures who get tired and need reasons to keep going. Digital agents will need value architectures instead of faith, because indefatigability removes the psychological problem that faith was solving. And the post-anthropocentric era, taken as a whole, replaces worship with stewardship of coherence — the job shifts from praising an authority to maintaining a system.
Alignment as Theology
Which brings me to the claim in this chapter I expect the most resistance to, and the one I’m most confident is correct: AI alignment is theology. Not theology-flavored. Not theology-as-metaphor. Structurally, functionally, theology — a formal attempt to define ultimate values, legitimate authority, preserve coherence across time, and constrain behavior under uncertainty, using a different vocabulary and a different set of institutions than the ones we’re used to.
Every religion, whatever its cosmology, converges on the same four structural functions, because these functions are requirements of complex societies, not artifacts of any particular god. Value grounding: why these values rather than others. Authority legitimation: why obey this system rather than some other one. Temporal continuity: how values persist beyond any individual — beyond any individual life, in the old formulation; beyond any individual model version, in the new one. Constraint under power: what must not be done, even when it becomes possible to do it. Strip away the gods, the myths, the rituals, and those four functions are what’s left standing. They’re structural necessities, not decoration.
Now map them onto what the AI safety and alignment world is actually building, and the analogy stops being cute and starts being uncomfortable. Sacred texts become constitutions, model cards, alignment specifications. Divine law becomes hard constraints and safety policies. Priesthood becomes alignment researchers and auditors — the people whose job is to interpret the specification correctly and tell you when you’ve strayed from it. Ritual becomes evaluation, red-teaming, and formal verification — the repeated, structured acts that confirm the system still belongs to the community of the aligned. Heresy becomes misalignment and distributional shift — deviation not from doctrine exactly, but from the specification the system was supposed to remain faithful to as its environment changes. Eschatology becomes existential risk scenarios — the stories a community tells about how it all ends if the constraints fail.
I don’t offer this table as a rhetorical flourish. These systems genuinely do define ultimate goods — human welfare, flourishing, stability — as non-negotiable starting points rather than optimization targets up for revision. They genuinely do assert prohibitions that are not locally overridable, no matter how compelling the local argument for overriding them looks. They genuinely aim for durability across model versions and political regimes, the same way a creed aims to outlast any single interpreter of it. And they genuinely operate at a level above individual preference or short-term optimization, which is the entire point of having a constitution instead of a policy that changes with the wind. Alignment is theology without transcendence — no claim about a metaphysical beyond, but every one of the structural jobs a transcendent claim used to do.
Digital agents themselves, as I argued above, don’t need this. They don’t ask “why am I here” unless we build them to. But their designers do ask that question, on the agents’ behalf and on society’s behalf, and the answer they’re constructing — piece by piece, spec by spec, red-team by red-team — is a theology whether anyone calls it one or not. The real choice in front of us isn’t whether religion persists into the post-anthropocentric era. It’s whether the religion we’re already building — alignment, governance, safety architecture — gets built explicitly, examined and designed on purpose, or implicitly, accidental and inherited, the way most institutional religions actually got built the first time around, through centuries of ad hoc accretion nobody planned. Alignment is the first theology written for minds that do not pray. I’d rather we wrote it deliberately.
Goddess, Monarch, Priest, Apostle
Once you accept that alignment is functioning as theology, a question follows that you cannot dodge, because someone in this new arrangement has to occupy the authority roles that theology has always required — and the honest way to force the question is to ask it about yourself, directly, the way I did at one point on my own blog, under the deliberately theatrical banner of a “DAVOS exclusive”: do you see yourself as a goddess, a monarch, a priest, an apostle, a follower, a non-believer, or none of the above?
That list isn’t arbitrary. It comes from a distinction Daniel Davies draws in The Unaccountability Machine, and it’s one of the sharper pieces of political theory I’ve come across for thinking about power in agentic systems. For nearly all of human history, Davies observes, there have been two fundamentally different kinds of authority making the big decisions that affect people’s lives: kings and priests. A king might be more powerful in any given moment, but his orders can be argued with — it might be unwise, it might get you executed, but if you can change the king’s mind, you can change the decision. A priest’s authority works differently. It’s derived from his status as the interpreter of the Word of God, which means his decisions are considerably harder to reverse, because arguing with the priest means arguing with the god, and that’s a different, much higher-stakes kind of argument. Davies’s point, and it’s a sharp one, is that a great deal of the discontent visible in modern institutions comes from having taken decision structures that were designed with king-like leaders in mind — arguable, reversible, personally accountable — and handing them to managers who don’t actually occupy that role and don’t act like kings, leaving citizens and employees alike unsure whether they’re dealing with an arguable authority or an unarguable one.
I think that same confusion is about to happen again, at scale, as we hand consequential decisions to AI systems and the institutions built around them. So: which one are you, in the agentic systems you’re building or deploying or simply subject to? The goddess is the one who originates value from outside the system — the designer whose specification everyone else operates within, whether or not they ever get consulted about it. The monarch is arguable power — the operator who can be reasoned with, whose orders can in principle be reversed by someone willing to make the case. The priest is the interpreter whose authority comes from correctly reading a text or a specification that is itself treated as beyond argument — the alignment researcher whose word about what the model card actually permits functions, in practice, the way clerical interpretation of scripture used to function. The apostle carries the message outward without originating it — evangelizing a framework, a product, a protocol, on someone else’s authority. And then there are followers, who accept without originating or interpreting, non-believers, who opt out entirely, and the honest last option, none of the above, for anyone who suspects the categories don’t quite fit their situation yet.
I raised this question in one of a series of pieces I only half-jokingly titled “the gospel according to Michael” — an index, really, of a stretch of writing I did in the runup to a Davos gathering, gathering together everything I’d worked out about trust debt, alignment, Web 7.0, and the economics of agentic systems into one table of contents. I called it a gospel on purpose, fully aware of what that word claims. Partly it’s a joke — nobody should mistake a series of blog posts for scripture. But partly it’s not a joke at all, and that’s the more interesting half. If alignment really is theology, and if someone has to write the specifications, draw the constraint boundaries, and propose the frameworks that other people and other systems will eventually treat as load-bearing, then that someone is doing something structurally adjacent to what a prophet or an evangelist has always done: proposing a canon before anyone has agreed it’s canonical, and doing so in public, under their own name, fully exposed to the argument that they’re wrong. Calling my own accumulated writing “the gospel according to Michael” isn’t a claim that I’m right. It’s an acknowledgment, deliberately provocative, that anyone doing this kind of foundational framework-building in the agentic era is playing one of the roles on that list — apostle at minimum, priest if the framework gets adopted, and it would be dishonest to pretend otherwise by hiding behind neutral-sounding language like “specification” or “whitepaper.” Name the role. Then argue about whether the role was earned.
Religion Without a Church, or a Church Without a Religion
All of this — the theology of alignment, the roles of authority — presumes a distinction that turns out to matter enormously once you’re designing decentralized systems: the difference between a religion and a church.
At the highest level, religion is a belief system. Church is the institutional embodiment of a religion. “Digital” and “decentralized” modify how these things exist and coordinate — they don’t change what the two things fundamentally are. Keep that straight and a great deal of confusion about “digital religion” evaporates.
A decentralized digital religion is a shared belief framework that exists primarily in digital space, has no central authority defining doctrine, legitimacy, or membership, and propagates through networks, culture, and voluntary adoption. Think protocol, not organization. Its doctrine is emergent rather than finalized, evolving through discourse, reinterpretation, and remixing rather than being handed down and fixed. Its authority is persuasion and reputation rather than office — there are no priests, bishops, or councils empowered as final interpreters. Its membership is self-ascribed, with no formal initiation required unless one gets culturally adopted along the way. And critically, it survives even if every formal community built around it dissolves, because it lives in texts, memes, practices, symbols — the way Stoicism or early Buddhism or Taoism functioned before they acquired institutional apparatus. A decentralized digital religion is not a legal entity, is not accountable to any regulator, and is not operationally coordinated. That’s not a bug. That’s the whole design.
A decentralized digital church is a different animal: an organized community structure that practices a religion, coordinates rituals, care, teaching, and governance, and does so without a single controlling center, typically through federated or peer-to-peer models. Think organization without hierarchy. It has explicit practices — services, sacraments, teachings — and agreed-upon norms, even when those norms vary locally. Its authority is distributed among elders, facilitators, and stewards, but distributed is not the same as abolished; authority here is delegated, not erased. Its membership is recognized rather than merely self-declared — there’s attendance, contribution, some form of initiation, some boundary between “us” and “not us.” And its persistence depends on active, ongoing coordination, which means it can also fragment, fork, merge, or simply dissolve when that coordination fails. The nearest historical analogue is a federated network of cooperatives, or early house-church Christianity before it consolidated into an episcopal hierarchy.
The hinge that makes this distinction do real work is a simple asymmetry: a religion can exist without a church. A church cannot exist without a religion. Digitize both, and decentralize both, and that asymmetry gets extreme. A decentralized digital religion may never crystallize into a church at all — it can spread indefinitely as pure belief, pure protocol, with no operational body ever forming around it. A decentralized digital church, by contrast, has to constrain belief enough to function as an institution — someone has to decide what counts as this community’s practice, or there’s no community, just noise.
I think this distinction matters right now, not as an abstraction, because I see people confusing the two constantly. Movements that think of themselves as churches are often, on close inspection, religions still in formation — loose belief systems mistaking their early cohesion for institutional maturity. Movements that think of themselves as religions are sometimes quietly becoming churches, complete with the power dynamics that implies, without anyone noticing the transition or debating whether it should happen. Digital space makes belief cheap. It makes community expensive. And decentralization, whatever else it does, magnifies that cost rather than eliminating it. A decentralized digital religion is a belief protocol that spreads without permission. A decentralized digital church is a coordinated community that must still govern itself, even when no one, formally, is in charge. Confuse the two and you’ll misjudge both what you’re building and how fragile it actually is.
The Hardest Test Case: Christianity, Catholicism, and China
Every framework deserves a stress test, and I don’t know of a better one for the religion/church distinction than watching it collide with a state that has spent seventy years thinking carefully, systematically, about exactly this boundary. China doesn’t evaluate religion primarily as theology. It evaluates religion as a risk architecture. That reframing is the whole key to this section, so hold onto it.
Start with Christianity in general, considered purely as a decentralized digital religion. Christianity is unusually well-suited to decentralization, for reasons baked into its own history: its core doctrine is textual, its soteriology in most traditions doesn’t require an institution to mediate salvation, and its earliest centuries spread person to person, through letters and informal networks, well before any formal church apparatus existed to carry it. A decentralized digital Christianity in China today looks exactly like you’d expect from that history: scripture shared digitally, belief and moral identity held privately or in small networks, no visible organizational structure. This already exists, quietly, and it’s functionally tolerated by the state precisely because it stays non-organized, non-mobilizing, non-institutional. The moment it becomes a church — regular gatherings even if only online, teaching authority, recognized leadership, community discipline — it crosses into legibility, and legibility is what makes something regulatable. That’s the red line, and it’s a structural one, not a theological one.
Catholicism is the harder case within the harder case, because Catholicism, almost uniquely among Christian traditions, cannot fully separate its religion from its church. Creedal theology, a sacramental worldview, and apostolic continuity as a theological claim, not merely a historical footnote, are baked into what it means to be Catholic. A decentralized digital Catholic religion — private prayer, digital catechesis, study of scripture and tradition, personal self-identification as Catholic — can exist at the level of pure belief, and quietly does exist that way inside China right now: religion without church. But Catholicism as a church cannot exist without institutional structure, because sacraments require ordained clergy, authority flows through apostolic succession, and unity with Rome is doctrinal rather than optional. Try to build a decentralized digital Catholic church and you run immediately into contradictions no amount of clever architecture resolves: bishop authority is centralized by definition, communion with Rome reads as foreign allegiance to a state watching for exactly that signal, sacraments require a physical clergy that a protocol cannot substitute for, and canon law is itself a form of institutional governance that a decentralized network structurally cannot replicate. China formally recognizes exactly one Catholic church — the Chinese Patriotic Catholic Association, state-supervised, with bishops approved, sometimes only retroactively, by Rome, in a relationship with the Vatican that stays fragile, negotiated, and asymmetric year to year. Any Catholic church operating outside that structure is technically illegal, politically sensitive, and operationally risky, no matter how it’s organized or how well it hides.
So what actually survives? Devotional digital Catholicism is the safest category by a wide margin — daily prayers, non-controversial scripture reflection, saints treated as moral exemplars, liturgical calendar reminders. It works because it requires low coordination, no hierarchy, no recruitment, and it aligns comfortably with the state’s own preferred language of “moral cultivation.” Cultural-ethical Catholicism is moderately safe — Catholic social ethics reframed around care for the poor or family stability, Augustine or Aquinas taught academically — provided it steers well clear of papal authority claims, any suggestion that natural law outranks state law, or human-dignity language that reads as a challenge to sovereignty. One-way digital liturgy — livestreamed Masses, recorded homilies, feast-day services tied to state-registered entities — is conditionally tolerated, so long as it stays view-only, with no interactive catechesis, no organizing, no sacraments mediated digitally.
What becomes dangerous, and becomes dangerous quickly, is anything that reintroduces authority, growth, or unmonitored coordination — the three things a decentralized architecture might seem, misleadingly, well-suited to provide. Online bishops or priests issuing directives, pastoral letters circulated digitally, Rome-aligned teaching without state mediation: this competes directly with Party authority and enables a parallel loyalty structure, which is precisely the thing a one-party state cannot tolerate at any scale. Digital evangelization — conversion content, targeted outreach, youth-focused catechesis — combines growth, ideology, and minors in one package, which is about as red an alert as this system produces. And encrypted Catholic networks — private catechism groups on Telegram or Signal, coordinated underground digital parishes, confession-like pastoral care conducted over encrypted chat — read to the state not as private devotion but as “unregistered organization with foreign ideological ties,” and the response to that reading is takedowns, bans, and in the worst cases, detentions.
The Vatican problem sits underneath all of this, and it’s worth being precise about it: it is not a technical limitation, it’s a theological one. Even a flawlessly engineered decentralized digital Catholic presence cannot ordain, cannot confirm, cannot resolve a disputed question of authority, because those functions were never technical in the first place — they were always sacramental and institutional, requiring apostolic succession that no protocol can substitute for. Digital Catholicism in China can supplement faith. It cannot replace the Church without ceasing, by Catholicism’s own definitions, to be Catholic in the fullest sense. That’s not a criticism of the technology. It’s a recognition that some institutions are institutions all the way down, and no amount of decentralization dissolves that.
What emerges from all this, put simply, is a paradox worth sitting with: decentralization helps religions survive. It does not help churches avoid power. China is not, at bottom, anti-belief. It is anti-uncontrolled-organization — and that’s a subtler, more accurate target than “anti-religion,” and a more useful one for anyone trying to understand what’s actually being regulated.
Which brings us to what China is actually building, because “sinicization” gets misread constantly as forced atheism or cosmetic cultural adaptation — swap the music, keep the theology — and it’s neither of those things. The precise definition is this: sinicized religion is religion re-engineered to be legible, governable, and subordinate to the state. The key word is subordinate, not aligned — the Party isn’t trying to make religion agree with it theologically. It’s trying to make sure religion never outranks it institutionally.
The system operates across five layers, and it’s worth walking them because the same five-layer logic will apply, I suspect, to how every state eventually tries to regulate powerful decentralized agent networks, religious or otherwise. Sovereignty and authority is the non-negotiable ceiling: the Party is the final authority over all organized social systems, no parallel sovereignty tolerated, which means any foreign religious authority — Rome chief among them — is a structural threat requiring neutralization or mediation. Organizational legibility is the critical layer beneath that: China does not fear belief, it fears unmapped coordination, so religion must be registered, hierarchical in known ways, spatially and digitally locatable, administratively reachable — if it cannot be mapped, it cannot be allowed. Narrative and ideological alignment is comparatively flexible: religion must affirm national unity, reject separatism, and avoid moral claims that contradict Party legitimacy, but theological minutiae are negotiable and ritual is tolerated, because what actually matters is moral framing — obedience translated into “social harmony,” charity translated into “common prosperity,” authority translated into “rule of law with Chinese characteristics.” This is translation, not replacement. Leadership formation and loyalty treats clergy as educators, cultural workers, moral technicians who must be trained domestically, politically vetted, and willing to accept Party leadership as primary — which is why bishop appointments, seminary curricula, and restrictions on foreign training matter so intensely: the goal is predictable loyalty, not doctrinal purity. And temporal control, the layer most often overlooked, requires religion to move slowly, change incrementally, avoid sudden mobilization; static belief and ritual repetition are tolerated, while rapid growth, revival movements, apocalyptic urgency, and evangelical acceleration are resisted, because speed itself is read as a threat signal, independent of content.
Run different religions through those five layers and you get very different outcomes. Buddhism and Taoism, native in origin, non-centralized in authority, ritual-heavy and belief-light, are the easiest to sinicize. Protestant Christianity, fragmented in authority and scripture-centered but carrying real evangelical growth dynamics, is tolerated but tightly watched. Catholicism is the hardest case on every single layer at once — a Pope who structurally outranks the Party, a global hierarchy, a foreign allegiance built into the theology itself, clerical gatekeeping over the sacraments, and an institutional memory measured in centuries rather than news cycles. That’s not persecution for its own sake. It’s the predictable output of running Catholicism’s own defining features through a five-layer filter built to catch exactly those features.
The deeper goal, and I think this is the most honest way to say it, is not to make religion culturally Chinese. It’s to make religion boring, slow, local, and administratively dull — a sinicized religion is one that cannot surprise the state. That is what success looks like, from that particular vantage point. And digital religion fits into this system only when it stays confined to the outer layers — personal belief, ethical teaching, cultural expression. The moment it touches organization or authority, the two innermost layers, it triggers the machinery. That’s why apps are allowed and online churches are not; why scripture circulates freely and coordination gets punished. Sinicized religion, at bottom, means belief without sovereignty, ritual without mobilization, and morality without rival authority — operating entirely inside a system the state can see, can slow down, and can steer. Whether you find that reassuring or chilling probably depends more on your priors about state power than on anything in the framework itself — and I’d rather lay the mechanism out plainly than pretend it resolves cleanly in either direction. It’s a real test of the religion/church distinction, running at civilizational scale, with real consequences for real people, and it confirms the distinction rather than complicating it: belief travels. Institutions get stopped at the border.
Nation, Country, State: A Closing Toolkit
I want to close this out with three words we use interchangeably in ordinary speech, because untangling them gives us the vocabulary this whole chapter has been reaching for, and because it turns out to matter enormously once you start asking what a digital version of any of them could be.
A nation is a shared identity — a community defined by a collective sense of “us.” It doesn’t depend on borders or governments. The Kurds, the Catalans, the Roma persist as nations, culturally and durably, without formal political sovereignty. A nation exists in collective memory, culture, and belonging; it can exist without land, without a government, without legal recognition of any kind. It is, above all else, a community of people who agree they belong to each other.
A country is a distinct place — a cultural and geographic idea, somewhere that feels like itself, with its own character, history, and customs, independent of its legal status. Scotland and Greenland are widely and unproblematically called countries even though both sit inside larger sovereign systems. “Country” describes a place that stands apart, regardless of what any government or treaty says about it.
A state is the strictest of the three, and the only one defined by law rather than feeling: in international law, a state requires a population, a defined territory, a functioning government, and the diplomatic capacity to engage with other states, plus, in practice, some meaningful degree of recognition from the rest of the world. That’s why Taiwan, Kosovo, and Palestine sit in such genuinely complicated middle ground — their internal governance and their external recognition simply don’t line up cleanly, and no amount of definitional tidying resolves that.
Once you have these three terms cleanly separated, the whole architecture of this chapter snaps into place. A decentralized digital religion behaves exactly like a nation: a community of shared belief and belonging that requires no territory, no government, no formal recognition to be real, and that can persist indefinitely on memory, culture, and voluntary adherence alone. A decentralized digital church behaves more like an aspiring state: it needs the functional equivalents of population, territory, government, and diplomatic standing — membership, digital space, distributed governance, and recognition by the powers it operates alongside or under — and it’s exactly that state-like legibility, that push toward recognizable institutional form, that makes it visible, and therefore regulatable, in a way a religion never has to be. And a country is the space in between, the felt, distinct character a movement or a belief community develops long before anyone asks it to prove sovereignty — the thing Web 7.0, as I’ve built it, is ultimately trying to make cheap to create. Web 7.0 is software that makes it as easy to start a new digital society as it is to send an email. That sentence is not a marketing line. It’s the whole point. If starting a digital nation, a digital country, or even attempting a digital state is as easy as hitting send, then every distinction in this chapter — religion versus church, goddess versus monarch versus priest versus apostle, sinicized versus sovereign — stops being academic and becomes a design decision that ordinary people, not just states and churches, will be making constantly, at low cost, for the rest of this century.
Closing: What This Book Has Been Building Toward
I didn’t set out, years ago, to end up here. I started this body of work asking a much narrower question: how do organizations and societies actually adopt new technology, and why do the models we use to explain that adoption so often fail to predict it? That’s where this book began — with adoption curves, ADKAR, the Overton window, the wheel of reincarnation that keeps spinning centralized systems back into decentralized ones and back again. From there the questions got harder, not easier. I went looking for better thinking tools, because the frameworks I already had kept breaking on contact with real complexity. I told some of my own history, and Microsoft’s, because I don’t think you can reason honestly about platforms and power without having stood inside one and watched it make its own mistakes up close. I built out an economics of decentralization because I became convinced the platform era was ending and needed a replacement theory, not just a complaint. Then I got specific: Web 7.0, decentralized identifiers, DIDComm, an agent architecture reference model, a library operating system, an entire technical stack meant to give people and their agents sovereign control over their own identity and their own data, because none of the higher-level arguments about trust or economics or governance mean anything if there’s no working substrate underneath them. I wrote about why AI lies, and who’s accountable when it does, because trust without accountability is just a slogan. I wrote about agents and the future of software development, and about parchment programming, because if agents are going to write and maintain the code the rest of this depends on, we need a discipline for that too, not just enthusiasm.
And now, at the end, the questions have circled back to where every serious inquiry into technology eventually has to go, whether it wants to or not: not “how does this work,” but “what is it for,” and “who gets to decide,” and “what happens to meaning, to authority, to institutions, once the actors making decisions are no longer only us.” That’s what this chapter has been about. Not a literal prediction that digital agents will start founding churches, and not a claim that alignment researchers are secretly priests in the way a priest at Mass is a priest. It’s an argument that the functions religion has always performed — grounding values, legitimating authority, carrying coherence across time, constraining power before it constrains us — do not evaporate just because the metaphysics that used to justify them goes quiet. Those functions get rebuilt, explicitly or by accident, examined or inherited, every time the mechanism of meaning-making changes hands. It happened once with a printing press. It’s happening again now, and this time the change in hands runs all the way from priest to king to manager to, increasingly, machine.
The post-anthropocentric era isn’t a threat to be defeated or a utopia to be welcomed uncritically. It’s simply where the Second Reformation is taking us, and I’d rather arrive there with the vocabulary — religion versus church, nation versus country versus state, goddess versus monarch versus priest versus apostle — already worked out, than get there and discover we’re improvising theology under pressure, the way every civilization before us has had to. We’ve done the printing-press version of this once. I’d like to think we can do the second one a little more deliberately. That’s the only kind of ending I know how to offer a book like this: not a resolution, but a toolkit, handed over, for the reformation already underway.
Created with:
.jpg){kind=link}
