The DCT problem 0.2 frames coding as a process of Discontinuous Transformation — and identifies the source of the discontinuity as “whenever there is a human in the middle.” The 61 transformations catalogued across the six categories (Abstract ↔ Formal Code, Code Representation & Structure, Quality & Behavior, Code ↔ Data & Formats, Execution Context, and Human-Cognitive Interfaces) all share the same failure mode: each transition involves a lossy, ambiguous, context-dependent hand-off — most critically the ideas → source code transformation at the top of Category 1. The human is the discontinuity.
Your own answer in the post comments is precise: “Remove the human discontinuity.” Parchment Programming is the methodology for doing exactly that.
How Parchment Programming Removes the Discontinuity
Parchment Programming is an architecture-first software development methodology where a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation (IR) that an AI coding assistant reads directly to generate correct, idiomatic code. Rather than translating requirements through layers of prose specifications, 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 key mechanism is the elimination of the ambiguous, lossy middle step. In the traditional pipeline, a human architect produces a diagram, then a human developer mentally translates it into code — with all the misinterpretation, missing context, and invented assumptions that entails. Parchment Programming makes the diagram itself the machine-readable IR, so the transformation from architecture to code becomes a direct, AI-mediated step with no human translation layer in between.
The PARCHMENT.md as a Continuous Transformation Surface
The PARCHMENT.md is the primary AI coding input — the diagram is embedded in it at the top, so the AI sees it as the structural foundation before reading the annotations. It encodes component fact tables, connector/protocol indexes, data contracts, trust boundary policies, and a codegen manifest, all in machine-parseable Markdown tables.
This structure directly addresses the DCT categories:
Category 1 (Abstract ↔ Formal Code): The diagram + PARCHMENT.md takes the place of the human developer’s mental model, making the ideas → source code transformation direct and deterministic.
Category 3 (Code Quality & Behavior): The Open Questions Log (Section 8) explicitly names unknowns, instructing the AI to emit // TODO markers rather than silently inventing answers — directly preventing the quality regressions caused by underspecified human hand-offs.
Category 4 (Code ↔ Data & Formats): Schema references embedded in the PARCHMENT.md (e.g., schemas/didcomm-envelope.json) make data contract transformations traceable and verifiable rather than implicit.
The Clean Separation of Concerns
The diagram handles spatial/structural truth; the companion PARCHMENT.md handles behavioral/contractual truth. This is a deliberate architectural choice that mirrors how compilers separate parse trees (structural) from semantic analysis (behavioral) — again reducing human interpretive variability at each stage.
Bottom Line
The DCT problem is essentially a problem of lossy intermediate representations wherever a human serves as the translation layer. Parchment Programming solves it by making the architecture diagram itself the lossless, AI-readable intermediate representation — replacing the human-as-translator with an AI-as-transformer operating on a richly structured artifact. The result is that the most expensive and error-prone DCT transition — ideas → source code — becomes a well-specified, reproducible, AI-mediated step rather than a creative act dependent on individual developer interpretation.
Principal @ Avestan, LLC | Hands-On Operations Leadership for Mid-Market and PE-Backed Companies | Interim COO | Contrarian Thinker | Avestan LLC
April 2, 2026
I should begin with a confession. I am neither a software engineer nor a market strategist. My knowledge of contemporary technology could fit comfortably on a thumbnail… and I say that as someone whose formal training is in electrical engineering, which will tell you how far I have wandered from my origins. The primary instruments of my early career were set squares and slide rules, which will tell you something about both my vintage and my domain. I have spent the intervening decades as a senior executive at Fortune 100 companies and, more recently, as an operations and supply chain consultant. I build and fix things: factories, supply chains, organizations that have lost their way.
Microsoft’s footprint is ubiquitous in the Seattle metro, from its sprawling Redmond campus, to the dedicated counters at Seattle-Tacoma airport, to the oversized coaches that ferry employees to and from work at no charge. It is, in every visible sense, a company that has built its own ecosystem within an ecosystem. Many of my neighbors are part of it…or were, until recently.
Which raises a fair question: what business does someone like me have offering a view on one of the world’s most sophisticated technology companies?
Possibly none. Or possibly this: thirty years of watching organizations succeed and fail has taught me that the early warning signals of institutional dysfunction are rarely technical. They are cultural, behavioral, and organizational… and they are often most visible to the outsider who has no stake in explaining them away.
That is the lens I am bringing. Take it for what it is worth.
What I am about to say is not a prediction of Microsoft’s future. It is a pattern recognition exercise. And the pattern, at minimum, gives me pause.
The Stock Is Telling You Something
Microsoft is down roughly 25% in Q1 2026, representing its worst quarterly performance since the depths of the 2008 financial crisis. This in a company that has delivered solid double-digit returns for three consecutive years. The earnings, objectively, remain strong: revenue up 17% year-over-year, operating margins north of 47%, cloud revenue exceeding $50 billion for the first time in a quarter.
And yet.
The market is not stupid, even when it overreacts. When a company of Microsoft’s scale and pedigree underperforms its peer group by double digits in a sector already under pressure the question worth asking is not “is this a buying opportunity?” The question is: what does the market understand about this organization that the headlines don’t capture?
I have a few hypotheses.
The Monopoly Dividend, and Its Hidden Cost
For the better part of three decades, Microsoft enjoyed something that very few companies in history have: a captive market. Enterprise customers did not use Office because they loved it. They used it because leaving was more painful than staying. That distinction – loyalty versus lock-in – matters enormously, and it is a distinction that organizations rarely make honestly about themselves.
When your customers cannot leave, the feedback loops that drive genuine innovation go silent. The tendency is to stop asking “what does the customer need?” and start asking “what can we get away with?” Processes multiply. Committees proliferate. Bureaucracy thrives. The organization optimizes for defending territory rather than creating it. The product becomes good enough rather than great, because great requires risk, and risk has no internal champion when the revenue arrives regardless.
This is not a character failing. It occurs insidiously and unconsciously. It is an entirely rational organizational response to a monopolistic competitive environment. But it leaves a mark. And that mark does not disappear simply because the competitive environment changes.
Satya Nadella Earned His Standing Ovation. The Work Isn’t Finished.
The Azure pivot was a genuine strategic achievement, and Nadella’s cultural reset from “know-it-all” to “learn-it-all,” as he framed it was real and necessary. The stack-ranking era that preceded him did generational damage to Microsoft’s ability to collaborate, retain talent, and take meaningful risks. He arrested that decline and deserves full credit for it. But here one must tread carefully. Stack ranking was formally abolished following Ballmer’s departure. The announcement was celebrated, the headlines were generous. What is rather more interesting is what one hears in conversations since. Ask Microsoft employees about the performance review system that replaced it, and the response is rarely enthusiastic. The words change, the architecture shifts, but the cynicism among those living inside it remains remarkably familiar. Whether the underlying mechanics genuinely changed, or whether the organization simply learned to dress the same instincts in more palatable language, is a question I cannot answer from the outside. What I can observe is that the people doing the work don’t appear to believe the answer is reassuring.
Moreover, cultural transformation in a 220,000-person organization moves at a glacial pace. You can change the language in a decade. Changing the instincts takes considerably longer. One has to wonder how many of the engineers and managers who learned to survive the Ballmer years by navigating politics rather than building products have since moved on…and how many remain, in leadership positions, still oriented by instinct toward self-protection over bold action. I cannot know that from the outside.
What I can observe is the output. Copilot – Microsoft’s most strategically critical product, promoted with the full weight of its marketing apparatus and sales force – has converted just 15 million paid subscribers from a captive base of 450 million Microsoft 365 users. That is 3.3%. I can offer a data point of one. I experimented with Copilot briefly, and it simply did not resonate. The alternatives were plentiful: I tried Gemini, ChatGPT, and Grok before eventually settling on Claude as the tool that genuinely fit the way I work. I am, by my own admission, hardly a sophisticated evaluator of these products. But that is rather the point. If a casual, non-technical user with no particular loyalty to any platform does not find his way back to Microsoft’s offering, one wonders what the experience is among enterprise customers with far more options and far higher expectations. When your own customers will not buy what you are selling at scale, it is worth asking whether the product is genuinely solving a problem, or whether it is simply a feature in search of a use case.
When the Organization Becomes the Obsession
There is a more intimate signal I would offer, drawn from lived experience rather than earnings reports. Spend enough time in social settings in this part of the Seattle corridor, and a pattern emerges: conversations with Microsoft employees have a pronounced gravitational pull toward the internal. Org charts. Reorgs. Internal processes. Who reports to whom now, and what that signals. Which team is ascendant, which is being quietly dismantled. I observed a version of this dynamic when I lived in Brookfield, Wisconsin, in the orbit of GE Healthcare’s then-headquarters. Large, complex organizations tend to generate internal politics that eventually colonize the social lives of their people. But what I observe here is of a different magnitude entirely. When internal politics becomes the primary currency of social conversation, it is usually a sign that navigating the organization has become more consuming than building anything within it. That is not a criticism of the individuals, rather it is a diagnosis of the system they are operating inside.
The OpenAI Dependency: A $281 Billion Question
Here is the number I find most remarkable in Microsoft’s recent disclosures: $281 billion. That is the portion of Microsoft’s $625 billion revenue backlog tied to contracts with a single counterparty – OpenAI.
Nearly half of Microsoft’s entire forward revenue commitment rests on the continued performance of an unprofitable startup navigating one of the most intensely competitive landscapes in the history of technology. And now, in what must rank among the more consequential strategic pivots of the past year, OpenAI has signed a landmark agreement with Amazon to host its enterprise platform on AWS! This is a move that directly challenges the Azure exclusivity Microsoft had long treated as a cornerstone of its AI strategy. For the uninitiated, this is roughly akin to UPS outsourcing its overnight delivery business to FedEx!
I have spent enough time in post-merger integrations and strategic partnerships to recognize the warning signs when a relationship’s terms of engagement shift this materially. The question is no longer whether the Microsoft-OpenAI partnership is evolving, because it clearly is. The question is whether Microsoft’s own AI capabilities can mature fast enough to reduce that dependency before the market loses patience entirely.
The reported reorganization of Copilot leadership and the broader restructuring of AI teams are not the confident moves of an organization executing a clear strategy. They read as the adaptive responses of one working to keep pace with events rather than ahead of them.
But the more consequential signal may be MAI-1, Microsoft’s internally developed AI model, built from the ground up as a hedge against its OpenAI dependency. Consider what that actually means: a company that has already committed eye-popping capital to an external AI partnership is now layering an enormously expensive and operationally complex internal model-building effort on top of that bet. A hedge on top of a bet, each of which is expensive, each of which carries execution risk, and neither of which has yet demonstrated the commercial returns that would justify the other. In portfolio management terms, this is not diversification. It is leveraged exposure dressed as prudence.
The Human Capital Story No One Is Writing
There is a dimension to this that the financial press has largely missed, and I raise it because I see it in my community every day.
A significant proportion of Microsoft’s engineering talent – and the engineering talent of the broader Seattle tech corridor – is comprised of H-1B visa holders. These are, by any measure, exceptional professionals: highly educated, deeply skilled, often carrying decade-long career investments in the United States. They have built lives here. Many have children born here. They have been, in many cases, the intellectual engine of the products Microsoft is depending on to compete in the AI era.
That population is operating under a level of personal anxiety right now that is, in my observation, without modern precedent. Travel advisories from their own employers. A $100,000 petition fee for new visa applications. Proposed rule changes touching birthright citizenship. A policy environment that sends a clear and unambiguous message: your presence here is conditional, negotiable, and subject to revision without notice.
The behavioral consequence of that anxiety is not visible in a quarterly earnings report. But it is real, and it is consequential. People operating under existential personal uncertainty do not take professional risks. They do not champion the bold new initiative. They do not volunteer for the high-visibility project that could fail. They execute reliably on what already exists and protect their position. In an organization that already has a cultural predisposition toward risk aversion, this compounds the pathology in ways that will show up…perhaps not this quarter, but in the product decisions made over the next eighteen months.
The Case for Optimism – And Why It Requires More Than Patience
None of this is to suggest Microsoft is broken beyond repair, and I want to be careful not to even hint at that. I am, after all, the person who opened this piece confessing that my knowledge of contemporary technology fits on a thumbnail. Betting against Microsoft has historically been an enterprise for the foolhardy. The balance sheet remains fortress-like. The enterprise relationships are genuinely extraordinary – ripping out Azure, Teams, and the M365 stack is not a decision any CIO makes lightly, regardless of Copilot’s penetration rate. The installed base moat is real, and should not be underestimated by anyone, least of all an operations consultant from the suburbs.
What I would offer, more modestly, is this: the bull case requires more than a great balance sheet, sticky product and deep customer relationships. It requires an organization capable of genuine innovation at speed, which in turn, requires a culture that rewards risk, retains its most creative talent, and executes with urgency. Whether Microsoft can summon those qualities at this particular moment is a question I cannot answer with conviction.
What I can say is that the market (which is considerably more qualified than I am) appears to be asking the same question. At 20 times forward earnings, the lowest multiple in a decade and briefly below the S&P 500 for the first time since 2015, it is not yet betting with conviction that the answer is yes.
Perhaps it should be. I honestly don’t know. What I do know is that the signals visible from outside the building – from the neighborhood, from social get-togethers, from the casual conversations – are worth paying attention to. They usually are.
Feroze Motafram is founder and principal of Avestan LLC, an operations-focused consultancy providing hands-on executive leadership to mid-market and PE-backed companies across supply chain, manufacturing, and operational excellence. With 30+ years of global experience, he partners with CEOs, operating partners, and investors to build resilient operations that drive enterprise value.
Post-nominal letters (PNL) appear after a person’s name to indicate qualifications, certifications, honors, or memberships—for example:
John Smith, PhD
Jane Doe, CPA
Alex Lee, P.Eng.
More formally, they fall under the broader concept of titles and credentials, but the specific term for the letters themselves is post-nominal letters.
For completeness:
Pre-nominal titles go before the name (e.g., Dr., Prof., Hon.)
Post-nominal letters go after the name (e.g., degrees, certifications, orders)
Here’s a structured, “post-nominal strategy space” for digital agents, with clear semantics rather than just decorative suffixes.
NOTE: Digital agent PNLs can be made machine-readable by representing them as DIDs from the did:pnl DID method.
1) What post-nominals mean (translated to agents)
For humans, post-nominals encode:
Qualification → what you know
License/authority → what you’re allowed to do
Role → what you currently are doing
Affiliation → who you act for
Reputation → how trusted/proven you are
For digital agents, you want the same—but machine-readable and composable.
2) Core strategy: modular, layered suffixes
Instead of one long suffix, think in stacked tokens, e.g.:
Parchment Programming is an architecture-first software development methodology where a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation (IR) that an AI coding assistant (like Claude) reads directly to generate correct, idiomatic code.
Rather than translating requirements through layers of prose specifications, 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 — invented by Michael Herman, Chief Digital Officer, Web 7.0 Foundation. April 2026.
“Change is hard at first, messy in the middle, and gorgeous at the end.” Robin Sharma
The core claim
PPML asserts that a formal diagram is a sufficient specification for code generation — that if a diagram is conformant (every element has a unique label, belongs to exactly one Legend-defined type, and has a derivation rule), then an AI or human can produce the correct implementation from the diagram alone, without additional prose specification.
This is a stronger claim than “diagrams are useful.” It is a claim about sufficiency.
Implication 1: The specification artefact changes
In conventional software development, the specification is prose — a requirements document, a design document, an architecture decision record. The diagram is illustrative, supplementary, and frequently stale.
In PPML, the diagram is the specification. The prose documents (TDA Design, Whitepaper, IETF drafts) are derived from the diagram — they explain and justify it, but they do not override it. If the diagram and the prose conflict, the diagram wins.
This inverts the usual relationship. The implication is that diagram maintenance becomes the primary engineering discipline, not prose authoring. A diagram change is a specification change. An undocumented code change that has no corresponding diagram change violates tractability — it is, by definition, undocumented behaviour.
Implication 2: AI code generation becomes deterministic at the architecture level
The Gap Register and derivation rules give an AI generator a closed-world assumption: every artefact it produces must be traceable to a diagram element instance, and every diagram element instance must produce at least one artefact. There are no open-ended requests like “build me a messaging system.” There are only grounded requests like:
“Derive the artefact for element instance ‘DIDComm Message Switchboard’ of type Switchboard. Derivation rule: one router class, one protocol registry, one outbound queue.”
The AI cannot invent artefact names that do not appear in the diagram. It cannot silently add dependencies. It cannot reorganise the architecture. This is not a limitation — it is the point. Creativity is in the diagram; precision is in the derivation.
The practical implication is that AI code generation quality is bounded below by the quality of the diagram, not by the quality of the prompt. A well-formed PPML diagram produces consistent, reproducible results across AI sessions and across AI models. A poorly-formed diagram produces inconsistent results regardless of prompt quality.
Implication 3: The change process becomes explicit
Conventional development has no formal mechanism for distinguishing “we changed the architecture” from “we changed an implementation detail.” Both look like pull requests.
PPML enforces a distinction. Within an epoch, the Legend is frozen and element types cannot change. A new component requires a diagram change, which requires a version increment (DSA 0.19 → DSA 0.24), which requires a Gap Register update. Architectural changes are visible as diagram changes.
Implementation changes — refactoring within a derived artefact, performance tuning, bug fixes — do not require diagram changes. The boundary between architecture and implementation is drawn precisely at the diagram boundary.
This has governance implications for a project like SVRN7: the diagram is the governance document. Epoch transitions are diagram changes. New protocol support is a LOBE addition to the diagram. The Foundation controls the diagram; contributors derive from it.
Implication 4: Testing becomes traceable to the diagram
Every test should be traceable to a diagram element instance, just as every artefact is. If a test has no corresponding diagram element, it is either testing an undocumented artefact (a tractability violation) or testing implementation detail that should not be exposed.
In practice this means the Gap Register can include test coverage as a property. “Element instance X has derivation artefact Y, test coverage Z.” Missing test coverage is a Gap Register entry, not a matter of developer discretion.
In conventional projects, diagrams go stale because they are maintained separately from code. PPML makes diagram staleness a first-class defect: if the diagram is stale, the Gap Register is wrong, and any AI-generated code derived from it will be wrong.
The practical discipline is: diagram first, always. Before writing any new C# class, PowerShell module, or LOBE descriptor, the diagram must already contain the corresponding element instance. This is why every source file in the SVRN7 solution carries a derivation trace comment:
That comment is not decorative — it is the traceability link. If that element instance no longer appears in the diagram, the file is either stale or the diagram is stale. One of them must change.
Implication 6: The methodology scales with AI capability
This is the forward-looking implication. In the current epoch, an AI (Claude, in this case) assists with derivation — producing C# from a diagram element description, writing PowerShell cmdlets from a LOBE derivation rule, generating IETF draft sections from an architectural decision. The human holds the diagram and reviews the derivations.
As AI capability increases, the human’s role shifts further toward diagram authorship and review. The diagram becomes the interface between human architectural intent and AI implementation. The better the diagram grammar (the PPML Legend), the more precisely an AI can translate intent into code.
The LOBE descriptor format — with its MCP-aligned inputSchema/outputSchema, compositionHints, and useCases — is an early instance of this. It is a machine-readable diagram-derived artefact that an AI can use to reason about composability without reading the PowerShell source. The diagram element (LOBE) produces both the code artefact (.psm1) and the AI legibility artefact (.lobe.json). Both are derived from the same diagram element. The AI consuming the .lobe.json is one step removed from reading the diagram directly.
The next step — which PPML explicitly anticipates but does not yet implement — is an AI that reads the diagram directly and performs the full derivation without a human intermediary for routine changes.
The honest limitation
PPML is most effective for component-level architecture — what components exist, how they relate, what they are responsible for. It is less effective for algorithmic detail. The 8-step transfer validator, the Merkle log construction, the DIDComm pack/unpack sequence — these require prose specification or pseudocode. The diagram says “TransferValidator exists and implements ITransferValidator.” It does not say how step 4 (nonce replay detection) works.
This is not a flaw in PPML — it is a boundary condition. PPML governs architecture. Algorithms require their own specification discipline (IETF drafts, pseudocode, formal methods). The two disciplines are complementary: PPML tells you what to build and how it connects; the algorithm specification tells you how each component behaves internally.
Summary
PPML’s implications reduce to one structural claim: the diagram is the primary engineering artefact, and all other artefacts are derived from it. The implications — specification inversion, deterministic AI generation, explicit change governance, traceable testing, structural documentation freshness, and scalability with AI capability — all follow from that single claim. Whether that claim is valuable depends entirely on whether the diagram can be kept accurate and complete, which is a discipline question, not a tool question.
Parchment Programming is an architecture-first software development methodology where a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation (IR) that an AI coding assistant (like Claude) reads directly to generate correct, idiomatic code.
Rather than translating requirements through layers of prose specifications, 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 — invented by Michael Herman, Chief Digital Officer, Web 7.0 Foundation. April 2026.
What folows is a structured comparison grounded in what Parchment Programming actually requires from a visual language.
What Parchment Programming Demands from a Visual Language
A PP visual language must do five things simultaneously:
Encode stereotypes that map to C# constructs («HostedService», «Repository», «Middleware»)
Annotate arrows with interface contracts and protocols
Be readable by Claude without a dedicated parser
Be authorable by a human architect without excessive tool friction
The Candidates
What You’re Using Now — Custom Annotated Box Diagrams
Verdict: Best starting point, needs formalization
Your DSA 0.16 diagram is already doing most things right. The color-coded regions, nested containment, labeled arrows, and protocol annotations are all PP-native. The gap is the absence of a formal stereotype vocabulary — Claude has to infer too much. A thin layer of formalization on top of your current style would make it the strongest option.
✅ Human-readable and visually expressive
✅ Claude can read it directly from an image
✅ Nested containment naturally maps to project boundaries
✅ No tool lock-in
❌ No enforced stereotype vocabulary (yet)
❌ Not machine-parseable without a defined grammar
ArchiMate
Verdict: Strong for enterprise/governance layers, wrong grain for C# code generation
ArchiMate excels at the motivation, strategy, and technology layers — it’s designed to show why a system exists and how it relates to business capabilities. Its stereotype vocabulary («ApplicationComponent», «ApplicationService», «DataObject») is too coarse and business-oriented to drive C# interface/class generation directly.
❌ No concept of IHostedService, «Middleware», DI registration
❌ Stereotypes don’t map cleanly to .NET constructs
❌ Claude reads ArchiMate OEF XML, not the visual — loses the PP directness
❌ Too ceremonial for rapid iteration
UML (Component + Class Diagrams)
Verdict: Closest formal precedent, but too verbose for PP
UML Component Diagrams handle bounded contexts and interfaces well. Class diagrams handle stereotypes («interface», «abstract», «service») and are the closest existing formal language to what PP needs. The problem is UML requires two diagram types to do what PP does in one, and the tooling (Enterprise Architect, Lucidchart) adds friction.
✅ «stereotype» notation is native and Claude knows it well
✅ Interface contracts expressible formally
✅ Claude has deep UML training — reads it very accurately
❌ Component + Class diagrams needed together — no single PP view
❌ No built-in protocol/messaging annotation
❌ Verbose; loses the architecture-at-a-glance quality
Verdict: Best structured alternative, but prose-first not diagram-first
C4 has the right levels (Context → Container → Component → Code) and maps well to .NET projects at the Container level. But it’s DSL-authored (Structurizr) or prose-prompted — the diagram is generated, not hand-crafted. That inverts the PP authoring model.
✅ Container level maps naturally to .csproj boundaries
✅ Component level maps to interfaces/classes
✅ Claude knows C4 well
❌ Diagram-as-code means the spec is the DSL text, not the visual
❌ No stereotype vocabulary for .NET-specific constructs
❌ Loses PP’s architecture-first visual authoring
The Recommendation
Define PP-Native Notation as a thin formal layer on top of your current style
Rather than adopting an existing language wholesale, Parchment Programming should define its own visual grammar — lightweight enough to author in any diagramming tool (PowerPoint, draw.io, Visio), rich enough to be unambiguously Claude-actionable. Concretely:
Borrow from UML: the «stereotype» notation — Claude reads it natively and it maps directly to C# constructs:
«HostedService» → : IHostedService, registered in DI
«Middleware» → app.Use...() in Program.cs
«Repository» → IRepository<T> pattern
«Router» → internal dispatch, no HTTP
«Gateway» → external system boundary
«PSModule» → PowerShell Loadable Brain Extension
«Factory» → Factory pattern, DI-registered
Borrow from ArchiMate: the nested containment model for bounded contexts — color regions = project boundaries.
Keep your current style: box shapes, color coding, directional arrows with protocol labels.
Add one new convention: every arrow carries [InterfaceName] in small text alongside the protocol label.
Summary Table
Language
Stereotype Support
.NET Mapping
Claude Readability
Authoring Ease
PP Fit
PP-Native (your style + UML stereotypes)
✅ Defined by you
✅ Direct
✅ Excellent
✅ High
⭐ Best
UML Component+Class
✅ Formal
✅ Good
✅ Excellent
⚠️ Verbose
2nd
C4 Model
⚠️ Coarse
✅ Good
✅ Good
⚠️ DSL-first
3rd
ArchiMate
✅ Formal
❌ Too coarse
✅ Good
⚠️ Ceremonial
4th
Mermaid/D2
❌ None
❌ None
✅ Excellent
✅ High
Last
Bottom line: Your current visual style is the right foundation — it just needs the «stereotype» convention from UML and the [InterfaceName] arrow annotation added as formal PP conventions. That makes it superior to any existing language for the specific job of AI-driven C#/.NET code generation.
Parchment Programming is an architecture-first software development methodology where a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation (IR) that an AI coding assistant (like Claude) reads directly to generate correct, idiomatic code.
Rather than translating requirements through layers of prose specifications, 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 — invented by Michael Herman, Chief Digital Officer, Web 7.0 Foundation. April 2026.
How Claude Processes Parchment Inputs
Claude receives a conversation context containing images + text. The key facts:
Claude can see a diagram image and reason about it
Claude can read structured Markdown/text with full fidelity
Claude cannot cross-reference between an image region and a text table by coordinate — it reasons about both holistically
Therefore: the diagram handles spatial/structural truth; the companion document handles behavioral/contractual truth
This is actually a clean separation of concerns.
The Recommended Hybrid Architecture
ParchmentSpec_DSA_0.16_Epoch0/
├── diagram.png ← the visual (spatial truth)
├── PARCHMENT.md ← master spec (behavioral truth)
└── schemas/
├── didcomm-envelope.json
├── did-doc.json
└── vc-doc.json
The PARCHMENT.md is the primary AI coding input. The diagram is embedded in it — not appended, not separate — embedded at the top, so Claude sees it as the structural foundation before reading the annotations.
- CIPHER algorithm selection: Ed25519 only or negotiated?
## 9. Excluded from AI Generation
- SVRN7 SRC transaction signing
- NEO4J CIPHER graph schema
- VTC7 federation handshake
Why This Works Best With Claude
The critical insight is section 8 — the Open Questions Log. Claude’s failure mode when coding from underspecified inputs is silent invention. Explicitly naming unknowns instructs Claude to emit // TODO: [OPEN QUESTION - LOBE hot-reload policy] rather than inventing an answer.
Three additional Claude-specific optimizations:
1. Use the diagram as a spatial index, not a spec. In your prompt to Claude, say: “The diagram shows containment and flow. The PARCHMENT.md sections 3–9 are authoritative for all behavioral details. Where they conflict, the Markdown wins.” This prevents Claude from over-reading visual ambiguities.
2. Keep sections 3–7 machine-parseable. Claude handles Markdown tables extremely well as structured input. Avoid prose paragraphs for anything that should drive code generation — tables and bullet lists are more reliably parsed into code structure.
3. Submit diagram + PARCHMENT.md together in every coding prompt. Claude has no persistent memory of previous sessions, so the full parchment must be present each time. The compact table format makes this token-efficient.
The Better Approach You Asked About
There is one additional technique worth considering: annotated diagram variants. Rather than modifying the master diagram, you maintain lightweight overlay versions for specific concerns:
diagram.png ← master (as-is, no changes)
diagram-trust-zones.png ← same diagram + colored zone overlays
diagram-dataflow.png ← same diagram + numbered flow sequence
These are fast to produce (PowerPoint/draw.io layer toggles) and can be embedded in targeted sections of PARCHMENT.md. Claude sees each as a focused lens on the same architecture without the master diagram becoming cluttered.
Bottom Line
Approach
Verdict
Annotate the diagram itself
Avoid — clutters the visual, hard to maintain
Companion Markdown only (no diagram)
Suboptimal — loses spatial/structural truth
Diagram embedded in PARCHMENT.md
✅ Recommended
Diagram + overlay variants + PARCHMENT.md
✅ Optimal for complex systems
The PARCHMENT.md is the intermediate representation. The diagram is its most important section — but only one section.
Parchment Programming is an architecture-first software development methodology where a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation (IR) that an AI coding assistant (like Claude) reads directly to generate correct, idiomatic code.
Rather than translating requirements through layers of prose specifications, 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 — invented by Michael Herman, Chief Digital Officer, Web 7.0 Foundation. April 2026.
Claude Prompt
How can this #ParchmentProgrammimg diagram be optimized as a design document/intermediate representation specification for a Claude AI-coded C#/.NET 8 software system?
Great diagram — this is a strong architectural foundation. Let me give you a structured analysis of how to optimize it as a ParchmentProgramming IR spec for Claude-coded C#/.NET 8.
What’s Already Working Well
The diagram communicates bounded contexts, data stores, messaging topology, and external federation clearly enough that Claude can infer C# project/namespace boundaries. That’s the core value of ParchmentProgramming: the diagram is the spec.
Optimization Recommendations
1. Add Stereotype/Type Annotations to Every Box
Right now Claude must infer whether a box is an interface, class, service, background worker, etc. Make it explicit:
Has anyone conceived of anything at all similar to Parchment Programming?
There are adjacent ideas in the ecosystem, but nothing that matches Parchment Programming’s specific inversion. Here’s the honest landscape:
Parchment Programming: What Exists — and Why It’s Different
Diagram-as-Code tools (Structurizr/C4, D2, PlantUML, Mermaid) go in the opposite direction — you write text and a diagram is generated, with elements automatically positioned by a layout engine. The diagram is the output, not the primary authoring artifact.
Swark / Claude Code go code → diagram — based on retrieved source files, an LLM builds a prompt to generate an architecture diagram as documentation. Again, the diagram is a byproduct of code, not a driver of it.
Eraser / DiagramGPT go natural language → diagram → code, but the diagram is an ephemeral intermediate — working with an LLM to create a fleshed-out diagram prompt is the workflow, not treating the diagram itself as an authoritative, annotated specification.
Structurizr comes closest in spirit — AI agents and LLMs excel at generating text, and Structurizr’s model-based consistency makes it a good choice for teams looking to generate C4 model diagrams with AI — but it’s DSL-first, not diagram-first, and carries no notion of the diagram encoding interface contracts or project boundary stereotypes for code generation.
Academic reverse-engineering approaches go code → diagram using LLMs, recovering both static and behavioral architectural views by extracting component diagrams and generating state machine diagrams to model component behavior. Still the wrong direction.
What Makes Parchment Programming Genuinely Novel
The field has thoroughly explored code → diagram and text → diagram → code. What nobody has formalized is the specific claim Parchment Programming makes:
The richly annotated visual diagram is the primary authoritative artifact — encoding stereotypes, interface contracts, project boundaries, and protocol modes — such that an AI reads it directly as an intermediate representation to generate correct, idiomatic code without a prose specification intermediary.
The key differentiators are:
(1) the diagram is architecture-first and human-authored, not AI-generated;
(2) it carries code-generation semantics embedded in the visual (stereotypes, interface names, DI boundaries); and
(3) it replaces the prose spec entirely rather than supplementing it.
That combination — as a named, intentional methodology — appears to be original to you.
Parchment Programming is an architecture-first software development methodology where a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation (IR) that an AI coding assistant (like Claude) reads directly to generate correct, idiomatic code.
Rather than translating requirements through layers of prose specifications, 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 — invented by Michael Herman, Chief Digital Officer, Web 7.0 Foundation. April 2026.
This article presents a structured analysis as well as the key optimization dimensions for diagrams used for Parchment Programming.
How can this #ParchmentProgrammimg diagram be optimized as a design document/intermediate representation specification for an AI-coded software system?
What the Diagram Does Well Already
Layered containment (TDA > Runspace Pool > Agent Runspaces) maps cleanly to class/module hierarchies an AI can scaffold
Named protocols (DIDComm V2, REST/HTTP, SQL/TDS, CIPHER) give an AI concrete interface contracts to target
Directional flow (Inbound Unpack → Switchboard → Outbound Pack) implies a pipeline pattern the AI can instantiate
Multiplicity hints (Agent 1…N, Citizen TDA ×4+) signal collection types and polymorphism requirements
The Six Optimization Gaps
1. Missing Cardinality & Lifecycle Annotations
The diagram shows what exists but not how many or when. An AI needs to know:
Is the Runspace Pool fixed-size or elastic? Min/max pool size?
Are LOBEs loaded at startup or on-demand?
Do Agent Runspaces share state or are they fully isolated?
Fix: Add a small Component Fact Table inset — one row per major component with columns: multiplicity | lifecycle (singleton/transient/pooled) | owns-state? | thread-safe?
2. Interface Contracts Are Implied, Not Declared
The AI sees “DIDComm/HTTP Listener” but has no method signatures, message schemas, or error contracts. The connector arrows carry no payload type.
Fix: Add stereotypes on connectors — e.g., label each arrow with «sends: DIDCommEnvelope» or «protocol: REST/JSON-LD». Even a short legend table mapping each arrow color/style to a message type and schema reference would let an AI generate correct interface stubs.
3. No Error / Exceptional Flow Representation
The diagram shows the happy path only. An AI coding from this will produce brittle code with no fault boundaries.
Fix: Add a Fault Boundary overlay — dashed red borders around components that must implement retry/circuit-breaker, and a small failure-mode legend: CIPHER fail → ?, LiteDB unavailable → ?, DIDComm unpack error → ?
4. Data Model is Storage-only, Schema-less
Four LiteDB stores are shown (Fast Cache, Long-Term Message Memory, DID Doc Registry, VC Doc Registry) but with no schema, key structure, TTL, or consistency requirements called out. The AI will invent schemas.
Fix: Add a Data Contract sidebar with one mini-schema per store — just the primary key pattern, top 3–5 fields, and TTL/eviction policy. For DID Doc Registry and VC Doc Registry this is especially important since did:drn and VC structure are normative.
5. Security / Trust Boundary is Structural but Not Behavioral
The CIPHER block and VTC7 boundary appear but the enforcement rules are invisible. When does encryption apply? Who authorizes a new LOBE load? What validates a VC before it enters the Runspace?
Fix: Add a Trust Boundary Annotation layer — color-coded zones (already partially present with the green/purple/yellow regions) with an explicit legend: green = TDA-internal trust, purple = DIDComm-authenticated, yellow = internet-untrusted. Add one-line policy statements per zone boundary crossing.
6. No Prompt-Injection Anchors (the Core #ParchmentProgramming Gap)
This is the critical one for AI-coded systems. The diagram has no named generation targets — no indication of which boxes map to which code artifacts, which interfaces must be hand-authored vs. AI-generated, or what the acceptance criteria are per component.
Fix: Add an AI Codegen Manifest — a table in the document (not necessarily in the diagram itself) with columns:
Component
Target Artifact
Generation Mode
Acceptance Test
PowerShell Runspace Pool
RunspacePoolManager.cs
AI-generated
Pool min/max respected
DIDComm Message Switchboard
DIDCommSwitchboard.cs
AI-scaffolded + hand-completed
Routes all registered message types
LOBE loader
LobeLoader.cs
AI-generated
Module isolation verified
SVRN7 XFER
Svrn7XferService.cs
Hand-authored
SVRN7 SRC ledger integrity
Structural Recommendations for the Document Form
If this diagram is the centerpiece of a Parchment Programming spec document, the optimal surrounding structure is:
1. System Identity Block ← version, epoch, DID of this spec doc itself
2. This Architecture Diagram ← with the fixes above applied
4. Connector / Protocol Index ← arrow → schema/interface mapping
5. Data Contract Sidebar ← per-store mini-schemas
6. Trust Boundary Policy ← zone rules in natural language
7. AI Codegen Manifest ← component → artifact → test mapping
8. Open Questions Log ← explicit unknowns the AI must not invent
The Open Questions Log (item 8) is underrated — explicitly flagging what is unspecified prevents an AI from silently hallucinating design decisions into generated code.
Quick-Win Priority Order
If you’re iterating the diagram itself (not the surrounding document), the highest-leverage single changes are:
Label every connector arrow with protocol + payload type — eliminates the largest source of AI ambiguity
Add lifecycle annotations to the LOBE and Agent Runspace boxes
Explicitly mark the DIDComm V2 trust boundary as the inbound validation gate
The diagram is already well above average as an AI coding input. These additions would move it from architectural sketch to generatable specification.
Has anyone conceived of anything at all similar to Parchment Programming?
There are adjacent ideas in the ecosystem, but nothing that matches Parchment Programming’s specific inversion. Here’s the honest landscape:
Parchment Programming: What Exists — and Why It’s Different
Diagram-as-Code tools (Structurizr/C4, D2, PlantUML, Mermaid) go in the opposite direction — you write text and a diagram is generated, with elements automatically positioned by a layout engine. The diagram is the output, not the primary authoring artifact.
Swark / Claude Code go code → diagram — based on retrieved source files, an LLM builds a prompt to generate an architecture diagram as documentation. Again, the diagram is a byproduct of code, not a driver of it.
Eraser / DiagramGPT go natural language → diagram → code, but the diagram is an ephemeral intermediate — working with an LLM to create a fleshed-out diagram prompt is the workflow, not treating the diagram itself as an authoritative, annotated specification.
Structurizr comes closest in spirit — AI agents and LLMs excel at generating text, and Structurizr’s model-based consistency makes it a good choice for teams looking to generate C4 model diagrams with AI — but it’s DSL-first, not diagram-first, and carries no notion of the diagram encoding interface contracts or project boundary stereotypes for code generation.
Academic reverse-engineering approaches go code → diagram using LLMs, recovering both static and behavioral architectural views by extracting component diagrams and generating state machine diagrams to model component behavior. Still the wrong direction.
What Makes Parchment Programming Genuinely Novel
The field has thoroughly explored code → diagram and text → diagram → code. What nobody has formalized is the specific claim Parchment Programming makes:
The richly annotated visual diagram is the primary authoritative artifact — encoding stereotypes, interface contracts, project boundaries, and protocol modes — such that an AI reads it directly as an intermediate representation to generate correct, idiomatic code without a prose specification intermediary.
The key differentiators are: (1) the diagram is architecture-first and human-authored, not AI-generated; (2) it carries code-generation semantics embedded in the visual (stereotypes, interface names, DI boundaries); and (3) it replaces the prose spec entirely rather than supplementing it. That combination — as a named, intentional methodology — appears to be original to you.
This document analyses the Web 7.0™ Decentralized System Architecture (DSA) v0.16 diagram and derives a complete design specification for the Citizen/Society Trusted Digital Assistant (TDA) — the sovereign, DID-native, DIDComm-native runtime at the centre of the Web 7.0 ecosystem.
The DSA diagram, captioned “Safe, Secure, Trusted, DID-native, DIDComm-native Web 7.0 DIDLibOS” and scoped to Epoch 0 (Endowment Phase), shows seven structural zones. This document reads each zone precisely, maps every component to the existing SVRN7 v0.7.1 C# library, and then specifies the four-layer TDA design: the DIDComm/HTTP Listener, the PowerShell Runspace Pool, the SVRN7 LOBE layer, and the LiteDB-backed storage tier.
Document Scope
Scope: This document is an architecture and design specification. It does not generate or modify any code. All design decisions recorded here are intended as the authoritative input to future implementation sprints.
Key Findings:
The TDA is a self-hosting, recursive unit: every Citizen TDA in the VTC7 mesh runs the same software at the same architectural level.
The DIDComm/HTTP Listener and the PowerShell Runspace Pool are deliberately separated: the Listener is a write-ahead log gate; the Pool is an execution environment. They share no threads.
The DIDComm Message Switchboard — named explicitly in the diagram inside Agent 1’s Runspace — is the single component that reads from the durable inbox (IInboxStore / svrn7-inbox.db) and dispatches to agent runspaces.
SVRN7 is positioned as a LOBE (Loadable Object Brain Extension), not as an agent task and not as a storage system. This is an architectural statement: the Shared Reserve Currency (SRC) is a cognitive capability available to all runspaces.
The SVRN7 XFER rail is a dedicated transfer channel independent of the DIDComm message bus, preventing monetary operations from competing with messaging I/O on the same file lock.
The Epoch 0 designation constrains the permissible transfer matrix. In Epoch 0 (Endowment Phase), citizens may transfer only to their own Society wallet or to the Federation wallet. Cross-Society citizen-to-citizen transfers (Epoch 1) and open-market operations (Epoch 2) are not yet active. All agent routing logic must enforce these epoch rules.
Reading the diagram from left to right, seven distinct structural zones are visible. Each zone has a clear role boundary; no two zones share responsibility.
Zone
Label
Description
1
Command-Line Interfaces (CLIs)
Human-facing surface: Windows/Linux, Android, iOS, and FireOS platform shells, plus a smartwatch UX. These are the entry points where human intent enters the system. No agent logic executes here.
2
Internet / LAN / P2P Transport Rail
A vertical transport bridge between the CLIs and the TDA interior. Explicitly transport-agnostic — Internet, LAN, and P2P are treated equivalently. DIDComm envelope security means the transport layer is untrusted and interchangeable.
3
Loadable Object Brain Extensions (LOBEs)
The cognitive/capability layer. Two LOBE blocks flank a central SVRN7 label. LOBEs are PowerShell Modules dynamically loaded into the Runspace Pool InitialSessionState. SVRN7 between the LOBEs signals that the Shared Reserve Currency is a first-class brain capability, not an external service.
4
Citizen/Society Trusted Digital Assistant (TDA)
The primary subject (green outer box). Contains the PowerShell Runspace Pool (red inner box) with Agent 1–N slots and the DIDComm Message Switchboard, plus the DIDComm/HTTP Listener (purple box) at the right edge.
5
Internet Cloud
Standard transport cloud bridging the TDA’s DIDComm/HTTP Listener to the VTC7 federation zone. Annotated arrows indicate Inbound Unpack and Outbound Pack operations at the Listener boundary.
6
Storage Layer
Four LiteDB databases (Fast Cache, Long-Term Message Memory, DID Doc Registry, VC Doc Registry), plus NEO4J (via CIPHER) and SQL Server (via SQL/TDS). A dedicated SVRN7 XFER channel connects the LOBE layer to the SOVRONA (SVRN7) SRC terminal.
7
Verifiable Trust Circles (VTC7)
Large blue arrow on the right encompassing five Citizen TDA nodes connected via purple DIDComm-secured connectors into a federated mesh. The architecture is recursive: each VTC7 peer is a full TDA instance running identical software.
The LOBE layer is the most architecturally distinctive zone. Two LOBE blocks are shown with a SVRN7 label centred between them. This layout carries three architectural assertions:
LOBEs are PowerShell Modules. In the v0.7.1 implementation they are Svrn7.Federation.psm1 (35 cmdlets) and Svrn7.Society.psm1 (15 Society-native cmdlets). They are loaded into the RunspacePool InitialSessionState once at startup, available to every runspace without per-invocation import cost.
SVRN7 is a brain capability. Its placement between the LOBEs — not inside the Runspace Pool and not in the storage layer — asserts that ISvrn7SocietyDriver is a cognitive faculty available to all agents as a direct in-process call, not a message-passing request to an external service.
A third LOBE slot is implied for domain-specific extensions (e.g., Society.Medicine.psm1, Society.Education.psm1). The architecture is open-ended: new capabilities are added as LOBEs, not as agent modifications.
The red inner box contains the Runspace Pool. Its named slots visible in the diagram are:
Agent 1 Runspace — Coordinator. Contains four specialised sub-agents (Email, Calendar, Presence, Notifications) and the DIDComm Message Switchboard (Inbound/Outbound). The Switchboard is the internal routing hub: every DIDComm message — whether arriving from the internet or generated by a sub-agent — passes through it.
Agent 3 — Invoicing. Processes payment and transfer request messages.
Agent N — Trading. Handles Epoch 1+ market operations. Inactive in Epoch 0.
Each of Agents 2–N has bidirectional arrows to the Switchboard, establishing it as the internal message bus. No agent communicates directly with another agent or with the DIDComm/HTTP Listener.
The purple box at the right edge of the TDA is the single inbound/outbound gate to the internet. Two annotations are explicit in the diagram:
Inbound Processing (Unpack) — upper annotation: all messages arriving from the internet are unpacked (JWE decrypted, JWS signature verified) before entering the system. The Listener never passes ciphertext to agent logic.
Outbound Processing (Pack) — lower annotation: all messages leaving the system are packed (JWS signed, then JWE encrypted via SignThenEncrypt). The Listener never sends plaintext over the internet.
A separate REST/HTTP rail runs alongside the DIDComm rail. This supports interactions (balance queries, transfer submissions from a mobile app) more naturally expressed as REST calls than as DIDComm messages.
The Switchboard is the most significant architectural element named in the diagram that is not yet explicitly modelled in the v0.7.1 codebase. The diagram shows it as a named, first-class component inside Agent 1’s Runspace with bidirectional arrows to every other agent. Its architectural role:
It is the sole reader of the durable inbox (IInboxStore / svrn7-inbox.db). No agent polls the inbox directly.
It inspects each message’s DIDComm protocol URI (“type” field) and routes it to the correct agent runspace.
It handles idempotency: if a TransferId has already been processed (via IProcessedOrderStore), it returns the cached packed receipt without invoking any agent.
It enforces epoch rules: messages of types not permitted in the current epoch are rejected with a DIDComm error response, not silently dropped.
The storage layer sits below the TDA and consists of six data stores:
Store
Technology / v0.7.1 File
Role
Fast Cache (LiteDB)
LiteDB or IMemoryCache
Holds last-N unpacked message bodies keyed by TransferId for duplicate-delivery acceleration. Bidirectional arrow to Long-Term Memory = cache-miss read-through.
Long-Term Message Memory
svrn7-inbox.db (IInboxStore)
All InboxMessage records with full Pending→Processing→Processed/Failed lifecycle. Implemented in v0.7.1.
DID Doc Registry
svrn7-dids.db (DidRegistryLiteContext)
Stores DidDocument records. Resolved via IDidDocumentResolver / LocalDidDocumentResolver / FederationDidDocumentResolver.
VC Doc Registry
svrn7-vcs.db (VcRegistryLiteContext)
Stores VcRecord records. Resolved via IVcDocumentResolver / LiteVcDocumentResolver / FederationVcDocumentResolver.
NEO4J (via CIPHER)
Neo4j Graph DB
Not yet implemented. Intended for graph-structured VTC7 trust relationship queries and Society governance lineage.
SQL Server (via SQL/TDS)
SQL Server
Not yet implemented. Intended for high-volume relational reporting, UTXO ledger analytics, and regulatory export.
The SVRN7 XFER dedicated channel connects the LOBE layer directly to the SOVRONA (SVRN7) SRC terminal at the bottom of the diagram. This is the UTXO transfer pipeline: Invoke-Svrn7Transfer → ISvrn7Driver.TransferAsync → 8-step validator → UTXO commit. The dedicated channel prevents monetary operations from competing with DIDComm message I/O on the same LiteDB file lock.
The large blue VTC7 arrow on the right encompasses five Citizen TDA nodes. Each node connects to neighbours via purple DIDComm-secured connector nodes. Three observations:
The architecture is recursive and peer-symmetric. Every Citizen TDA in the mesh runs the same software. There is no central broker. The purple connectors represent the DIDComm/HTTP Listener instances of each peer TDA.
Cross-Society communication flows through Listener instances only, not through a shared database. FindVcsBySubjectAcrossSocietiesAsync and FederationDidDocumentResolver implement this fan-out pattern in v0.7.1.
VTC7 governance is enforced by the LOBE layer, not by network topology. A TDA that presents a valid Society DID and a current Svrn7VtcCredential VC is a legitimate VTC7 member.
The diagram’s Epoch 0 designation aligns precisely with Svrn7Constants.Epochs.Endowment (= 0) in the v0.7.1 codebase. The transfer epoch matrix enforced by TransferValidator Step 2 (ValidateEpochRulesAsync) covers all three epochs and requires no code changes. The Switchboard needs to read the current epoch via Get-Svrn7CurrentEpoch before routing trading messages.
Epoch
Constant
Permitted Operations
Epoch 0 — Endowment
Svrn7Constants.Epochs.Endowment
Citizens may transfer only to their Society wallet or the Federation wallet. Switchboard rejects trading/1.0/* messages.
Epoch 1 — Ecosystem Utility
Svrn7Constants.Epochs.EcosystemUtility
Cross-Society citizen-to-citizen transfers permitted. Agent N (Trading) becomes active.
Epoch 2 — Market Issuance
Svrn7Constants.Epochs.MarketIssuance
Open-market operations. Full VTC7 mesh trading enabled.
The following layers specify the complete TDA design. No code is generated here; this is the design record from which implementation sprints are planned.
A minimal Kestrel HTTP server (ASP.NET Core minimal API, no MVC) running on a configurable port. The Listener is the single inbound/outbound gate to the internet. It has exactly one responsibility: receive packed messages, unpack them at the cryptographic boundary, and enqueue them for processing.
Layer Boundary Rule
Design Rule: The Listener never executes agent logic. It only enqueues. The Runspace Pool never binds to a port. It only processes. These two systems share no threads and no direct call paths.
POST /didcomm — Receives a packed DIDComm message (Content-Type: application/didcomm-encrypted+json). Calls IDIDCommService.UnpackAsync to verify and decrypt. Calls IInboxStore.EnqueueAsync(messageType, unpackedBody). Returns 202 Accepted immediately. If UnpackAsync fails, returns 400 Bad Request with a DIDComm problem-report — no message is enqueued.
POST /rest/transfer — Convenience REST endpoint for synchronous UX-driven transfer submissions. Validates a signed TransferRequest JSON body and calls ISvrn7SocietyDriver.HandleIncomingTransferMessageAsync directly. Returns 200 OK with the packed receipt.
GET /health — Returns JSON health status: inbox queue depth by status, Merkle tree head age, current epoch, Listener up/down. Used by the smartwatch UX and monitoring.
All inbound messages are unpacked before anything else. Unpack = JWE decrypt using the Society’s Ed25519 messaging private key + JWS signature verify using the sender’s Ed25519 public key. Both steps must succeed; a failure at either point results in 400 and no enqueue.
All outbound messages are packed before leaving the Listener. Pack = JWS sign using the Society’s Ed25519 private key, then JWE encrypt using the recipient’s Ed25519 public key (SignThenEncrypt default, matching DIDCommPackMode throughout v0.7.1).
Agents work with plaintext only. This is the invariant enforced by the Pack/Unpack boundary. Runspaces never need access to cryptographic keys.
A LobeManager singleton reads a lobes.config.json manifest at startup, listing module paths in load order. It creates a shared InitialSessionState with each LOBE pre-imported and a shared $SVRN7 session variable (a Svrn7RunspaceContext object) injected into every runspace.
The Svrn7RunspaceContext holds:
A reference to the ISvrn7SocietyDriver singleton.
A reference to the IInboxStore singleton (svrn7-inbox.db).
A reference to the IProcessedOrderStore singleton.
The current epoch value, refreshed periodically via Get-Svrn7CurrentEpoch.
A RunspacePool with configurable min/max (recommended: min=2, max=ProcessorCount×2). Each runspace shares the same InitialSessionState from the LobeManager. The pool is not shared with the HTTP Listener thread.
Agent 1 is always open (min runspaces ≥ 1). It owns the DIDComm Message Switchboard and four specialised sub-agents.
DIDComm Message Switchboard
A continuous loop running inside Agent 1’s Runspace on a dedicated thread (not a PeriodicTimer — it runs with a short sleep on empty inbox). Its processing cycle:
Wraps Microsoft.Graph or Exchange EWS PowerShell commands. Cross-references sender email addresses with Society member DIDs via Resolve-Svrn7CitizenPrimaryDid. Structured results are placed back into the Switchboard’s outbound queue.
Calendar Sub-Agent
Reads and writes calendar events via Microsoft.Graph. Calendar events can carry did: URI identity claims in their extended properties, linking appointments to Society membership records and VTC7 governance meetings.
Presence Sub-Agent
Publishes the TDA’s availability status as a https://svrn7.net/protocols/presence/1.0/status DIDComm message to subscribed VTC7 peers. Receives presence updates from peers and maintains a local presence cache.
Notifications Sub-Agent
Dispatches alerts to the UX layer (smartwatch, mobile) when: inbox depth exceeds a configurable threshold; a citizen’s SVRN7 balance changes by more than a configurable amount; a Verifiable Credential is within 7 days of expiry; or the Society wallet balance falls below CitizenEndowmentGrana (overdraft draw trigger).
Each task runspace is opened from the pool on demand by Invoke-AgentRunspace and returns to the pool when the task completes. The pool thread is occupied only for the duration of the operation.
The SVRN7 XFER rail in the diagram is a dedicated channel from the LOBE layer to the SOVRONA SRC terminal. A SvrN7TransferService BackgroundService is designed to run alongside DIDCommMessageProcessorService:
Agents post a TransferQueueRecord to a dedicated ITransferQueue collection in svrn7-inbox.db rather than calling ISvrn7Driver.TransferAsync directly.
SvrN7TransferService drains ITransferQueue on its own loop, runs the 8-step TransferValidator, and commits the UTXO.
Retry semantics: up to 3 attempts (mirroring IInboxStore). After maxAttempts, the record is dead-lettered with LastError populated.
This decouples agent logic from the UTXO commit path and prevents monetary operations from competing with DIDComm inbox I/O on the same LiteDB file lock.
Five principles emerge from careful reading of the DSA diagram. These are structural rules that the diagram enforces by its construction, not interpretive opinions.
#
Principle
Definition
Rationale
P1
Listener and Pool are separate systems
The Listener never executes agent logic; it only enqueues. The Pool never binds to a port; it only processes. No shared threads.
Prevents a slow agent from blocking inbound receipt. Prevents a message burst from exhausting runspaces.
P2
Switchboard is the sole inbox reader
No agent polls IInboxStore directly. Only the Switchboard does, then hands work to agent runspaces.
Single point for epoch enforcement, idempotency checking, and routing. Single LiteDB writer.
P3
Pack/Unpack at Listener boundary only
Agents work with unpacked plaintext. Agents produce plaintext responses; the Listener packs them.
Security guarantee (no agent receives unverified data) and architectural simplification (runspaces need no crypto keys).
P4
SVRN7 is a LOBE, not an agent
ISvrn7SocietyDriver is available to all agents via $SVRN7 session variable — direct in-process cmdlet invocation, not message-passing.
This is why SVRN7 sits between the LOBE blocks in the diagram, not inside a specific agent box.
P5
VTC7 peers are structurally identical
Every Citizen TDA in the mesh runs the same software. No central broker. Cross-Society communication flows through DIDComm/HTTP Listener instances only.
Self-hosting, recursive design. FindVcsBySubjectAcrossSocietiesAsync and FederationDidDocumentResolver implement the fan-out pattern.
Components identified in the diagram but not yet implemented in SVRN7 v0.7.1, representing the work backlog for future sprints.
Gap
Priority
Design Decision
HTTP/Kestrel Listener Entry Point
Critical
ASP.NET Core minimal API with POST /didcomm (enqueue), POST /rest/transfer (synchronous), and GET /health routes. Calls IInboxStore.EnqueueAsync. This is the missing bridge between the internet and DIDCommMessageProcessorService.
DIDComm Message Switchboard (named)
Critical
Extract routing logic from DIDCommMessageProcessorService into a named SwitchboardService with explicit epoch gating, IProcessedOrderStore idempotency check, and per-protocol-URI routing to agent runspace slots.
Svrn7RunspaceContext + $SVRN7
High
Formalise the $SVRN7 PSCustomObject as a named class holding ISvrn7SocietyDriver, IInboxStore, IProcessedOrderStore, and current epoch. Inject via RunspacePool InitialSessionState.
LobeManager + lobes.config.json
High
Singleton that reads the manifest, builds the InitialSessionState, and manages hot-reload of domain LOBEs without full TDA restart.
Agent 1 Sub-Agents (Email, Calendar, Presence, Notifications)
High
Four PowerShell pipeline scripts inside Agent 1 Runspace. Microsoft.Graph for Email and Calendar. Custom DIDComm presence/1.0/status protocol for Presence. Event-driven Notifications.
Fast Cache (svrn7-cache.db)
Medium
CacheLiteContext (fifth LiteDB) or IMemoryCache. Stores last-N TransferId → packed receipt pairs for Switchboard hit-before-dequeue.
SvrN7TransferService + ITransferQueue
Medium
Dedicated BackgroundService draining a TransferQueueRecord collection in svrn7-inbox.db, decoupling agent UTXO commit from agent message processing.
Agent N — Trading
Low (Epoch 1)
Implement when Get-Svrn7CurrentEpoch returns ≥ 1. Switchboard routing stub (drop trading/* in Epoch 0) should be added now.
NEO4J / CIPHER integration
Low (Future)
Graph store for VTC7 trust path queries. Out of scope for v0.7.x.
Trusted Digital Assistant. The sovereign, DID-native, DIDComm-native runtime at the centre of the Web 7.0 ecosystem. A citizen or Society operates one TDA.
DSA
Decentralized System Architecture. The architectural diagram describing the TDA and its surrounding ecosystem. Current version: DSA v0.16.
LOBE
Loadable Object Brain Extension. A PowerShell Module loaded into the Runspace Pool InitialSessionState, providing capabilities (SVRN7 cmdlets, domain functions) available to all runspaces.
VTC7
Verifiable Trust Circle. A federated mesh of TDA nodes that mutually recognise each other’s DIDs and VCs, enabling cross-Society communication and cross-Society VC resolution.
SRC
Shared Reserve Currency. The SVRN7 / SOVRONA monetary unit. 1 SVRN7 = 1,000,000 grana. Citizen endowment in v0.7.1: 1,000 grana = 0.001 SVRN7.
DIDComm
Decentralized Identifier Communication. A message protocol providing transport-agnostic, end-to-end secure messaging between DID-identified parties. Version 2 used throughout Web 7.0.
SignThenEncrypt
The default DIDComm pack mode in SVRN7 v0.7.1. Payload is JWS-signed with the sender’s Ed25519 private key, then JWE-encrypted with the recipient’s Ed25519 public key (X25519 via RFC 7748 birational map).
Switchboard
The DIDComm Message Switchboard. Named component inside Agent 1’s Runspace. The sole reader of the durable inbox. Routes messages to agent runspaces by protocol URI.
Pack / Unpack
Pack = sign + encrypt an outbound DIDComm message. Unpack = decrypt + verify signature on an inbound message. Both operations occur exclusively at the Listener boundary.
Epoch
A governance phase of the SVRN7 ecosystem. Epoch 0 (Endowment): citizen→Society and citizen→Federation transfers only. Epoch 1 (Ecosystem Utility): cross-Society. Epoch 2 (Market Issuance): open-market trading.
UTXO
Unspent Transaction Output. Atomic unit of SVRN7 wallet balance. Every transfer creates new UTXOs and marks spent UTXOs. Conservation invariant: sum of all UTXOs = TotalSupplyGrana − unallocated Federation balance.
grana
Atomic monetary unit of SVRN7. 1 SVRN7 = 1,000,000 grana. All storage, arithmetic, and transfer amounts are in grana. SVRN7 is display-only.
Here’s a structured breakdown, distinguishing what’s established fact, inference, and uncertain.
Who Owns Content Claude Creates?
1. Anthropic’s Terms: You Get the Output Rights
Under Anthropic’s Consumer Terms of Service, as between you and Anthropic, you retain any right, title, and interest in the inputs you submit. Subject to your compliance with their terms, Anthropic assigns to you all of their right, title, and interest — if any — in the outputs.
The “if any” qualifier is doing real legal work there. Anthropic is assigning whatever rights they have in the output — but they’re not guaranteeing those rights are substantial under copyright law.
For commercial/API customers, the terms are stronger. The commercial terms state that Anthropic agrees the customer owns all outputs, and disclaims any rights it receives to customer content, assigning all right, title, and interest in outputs to the customer.
2. Copyright Law: The Human Authorship Problem
This is where it gets complicated. U.S. copyright law requires a human author. The U.S. Copyright Office has been clear on this — a federal court ruled that art generated entirely by AI couldn’t be copyrighted because it lacked the essential human touch. So if you give Claude a simple prompt and use the raw, unedited output, that content likely has no copyright protection at all.
In February 2026, the Supreme Court declined to hear the Thaler appeal, confirming at the highest level that pure AI-generated works cannot be copyrighted.
The practical implication: The more creative direction, editorial judgment, and human selection you exercise over Claude’s output — revising, curating, combining, structuring — the stronger your claim to copyright over the resulting work. The output becomes a human-authored work with AI assistance, rather than an AI-generated work.
3. Commercial Use and Reuse Rights
Anthropic’s terms confirm users own outputs generated by Claude, and commercial use is permitted without additional licensing. So you can publish, sell, or incorporate Claude-assisted content into your work — no royalty or license back to Anthropic is required.
4. Copyright Indemnity (API/Commercial Customers)
Under Anthropic’s Commercial Terms of Service, Anthropic will defend customers from any copyright infringement claim made against them for their authorized use of the services or their outputs, and will pay for any approved settlements or judgments that result. This does not apply to consumer/claude.ai free-tier users in the same way.
Practical Summary for Your Situation
Given that you’re using Claude for SVRN7/Web 7.0 specification work, whitepaper drafting, IETF drafts, and software architecture — the key points are:
You own the outputs under Anthropic’s terms (both consumer and commercial).
Copyright protection on purely AI-generated text is legally uncertain — but content you meaningfully shape, edit, and structure has stronger human-authorship claims.
Publishing rights: No restriction from Anthropic on original publication — you can publish IETF drafts, W3C specs, whitepapers, and code incorporating Claude-assisted content.
Strongest position: Document your creative contributions — the architectural decisions, structural choices, and editorial revisions you make to Claude’s outputs. That’s where your copyright lives.
I’m not a lawyer, and this space is evolving rapidly with active litigation. For anything with significant commercial stakes, legal counsel familiar with AI IP would be worth consulting.
Web 7.0 DIDLibOS™ / TDW AgenticOS™ / Hyperonomy™ Digital Identity Lab 