Monthly Archives: April 2026

Create your own magic with Web 7.0 DIDLibOS™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DIDLibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

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.

Part 2 can be found here: https://hyperonomy.com/2026/04/09/parchment-programming-diagramic-design-document-intermediate-representation-optimization-part-2/

Parchment Programming Methodology: https://hyperonomy.com/2026/04/09/parchment-programming-methodology/

Claude Prompt

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
• Technology bindings (LiteDB, NEO4J, SQL Server, PowerShell Modules) eliminate ambiguity in dependency selection
• 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:

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
3. Component Fact Table         ← multiplicity, lifecycle, ownership
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:

1. Label every connector arrow with protocol + payload type — eliminates the largest source of AI ambiguity
2. Add lifecycle annotations to the LOBE and Agent Runspace boxes
3. 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.

Part 2 can be found here: https://hyperonomy.com/2026/04/09/parchment-programming-diagramic-design-document-intermediate-representation-optimization-part-2/

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DIDLibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Who owns the content that you create? Who owns the copyright? And what are the rights for reuse or for original publishing?

Reference: https://claude.ai/share/55c3e4d4-edd2-44a3-b586-52fee2a5fc30

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.

Create your own magic with Web 7.0 DIDLibOS™ / TDW AgenticOS™. Imagine the possibilities.

Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public License
Web 7.0™, Web 7.0 DIDLibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

Abstract

Traditionally when a platform developer (e.g. Microsoft) created a new platform, it embarked on standard approaches to Developer Evangelism to challenge the various Technology Adoption Curves and to Cross the Chasm (e.g. https://hyperonomy.com/2019/10/16/technology-adoption-models/). In the new era of AI-generated code, where/how should evangelism be targeted? …if it can even be called evangelism any more. How should a platform developer promote his new platform to all the different AI chatbots (e.g. Claude)? What artifacts need/should be created? Where/how should they be placed/distributed? This is a rich and important strategic question.

Platform Evangelism in the Age of AI-Generated Code

The Fundamental Shift: From Human Adopters to AI Intermediaries

Traditional Developer Evangelism targeted humans at specific positions on the Technology Adoption Lifecycle — Innovators, Early Adopters, Early/Late Majority, Laggards. The evangelist’s job was to move people rightward along that curve.

In the AI-generated code era, a new and decisive intermediary has been inserted into the adoption pipeline: the AI coding assistant / chatbot. The human developer no longer discovers your platform primarily through conference talks, blog posts, or Stack Overflow. Instead, they ask Claude (or Copilot, Cursor, 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, the human never even gets a chance to adopt.

The implication is stark: AI models are now the most important Early Adopters you need to cross the chasm with first. They are a new, synthetic segment that sits before the Innovators on your adoption curve.

The New Adoption Curve Layer

Your 20+ model framework maps well here. Superimposing two layers:

What Has Changed About “Evangelism”

The word still applies, but the audience, artifacts, and channels are fundamentally different.

Old evangelism targets:

• Human developers (via conferences, blogs, sample apps)
• Enterprise architects (via whitepapers, reference architectures)
• CTOs (via analyst reports, Gartner quadrants)

New evangelism targets (primary):

• AI training pipelines — what gets into the pretraining and fine-tuning corpora
• AI retrieval systems — what gets surfaced via RAG at inference time
• AI context windows — what gets injected via system prompts, MCP servers, tool definitions
• AI safety/quality filters — what AI providers consider authoritative and trustworthy

The humans still matter, but they are now downstream of the AI intermediary.

The New Artifact Set

This is where it gets concrete. You need a new category of artifact that I’d call AI-Legible Platform Documentation — content designed to be consumed, reasoned over, and reproduced by AI systems, not just read by humans.

1. llms.txt — The Emerging Standard

A plain-text or markdown file placed at the root of your platform’s documentation site (e.g., https://svrn7.net/llms.txt). This is an emerging informal standard (analogous to robots.txt) that signals to AI crawlers and RAG systems what your platform is, what its key concepts are, and where the authoritative docs live. It should be:

• Terse, structured, machine-readable
• Canonical definitions of your core concepts (did:drn, VTC, SOVRONA, etc.)
• Explicit disambiguation (e.g., “SOVRONA is not Solana, not SOVRIN”)

2. Canonical Concept Glossary (Machine-Readable)

A JSON-LD or plain markdown file with precise, unambiguous definitions of every platform term. AI models pattern-match on concept names. If your terms are unique enough (which did:drn, VTC7, svrn7.net largely are) and appear in training data with consistent definitions, the model learns authoritative meaning. Publish this as both human-readable HTML and structured data.

3. AI-Optimized Quickstart / Code Recipes

Short, self-contained code examples (C#/.NET in your case) that demonstrate each key integration scenario. These need to be:

• Complete — no ellipsis (...), no “fill in your own logic here”
• Correct — compilable, with real method signatures
• Labeled — preceded by a natural-language description that an AI can use as a retrieval key
• Published in plain markdown — not behind JavaScript-rendered walls

The goal: when a developer asks Claude “how do I resolve a did:drn identifier in C#?”, there is a verbatim-correct code sample in the training data or retrieval index that Claude surfaces.

4. OpenAPI / SDK Schemas

If your platform has any API surface, publish machine-readable schemas (OpenAPI 3.x, JSON Schema). AI coding assistants consume these directly — Copilot, Cursor, and others can ingest them to generate type-correct API calls. This is one of the highest-leverage artifacts you can produce.

5. MCP Server Definition

For platforms targeting agentic AI workflows (which Web 7.0 / TDW AgenticOS clearly does), publishing an MCP server that exposes your platform’s key operations is the equivalent of publishing an SDK in the old world. When a developer is using Claude with MCP enabled, your platform becomes natively callable. This is arguably the highest-leverage evangelism artifact in the agentic AI era.

6. IETF / W3C Standards Drafts (Already in Progress)

This is something you’re already doing, and it is directly high-value for AI training. Standards bodies’ outputs (IETF Datatracker, W3C, etc.) are heavily weighted in AI training corpora. draft-herman-did-drn-00 appearing on Datatracker means AI models encounter it as an authoritative source. This is the new equivalent of a Gartner mention.

7. GitHub Presence with Rich READMEs

GitHub is a primary training data source for all AI coding assistants. Every repository should have:

• A detailed README explaining the why and what of the platform
• Clear installation/usage examples
• Properly named types, interfaces, and methods (because AI learns your API surface from source code identifiers)

Where / How to Place and Distribute

The Meta-Insight: Legibility as the New Evangelism

In the traditional model, evangelism was about persuasion — moving humans emotionally and rationally across the adoption chasm. In the AI-mediated model, the equivalent is legibility: making your platform concepts, APIs, and code patterns so precisely and consistently expressed that AI models can reproduce them correctly.

A poorly documented platform that generates hallucinated API calls when asked about it is effectively invisible to the new generation of developers. A well-documented platform that produces correct, idiomatic code snippets on first ask has already crossed the chasm with the most important new gatekeeper.

If you want a new term for it: AI Legibility Engineering — the discipline of structuring your platform’s knowledge artifacts so they are accurately learned, retrieved, and reproduced by AI systems.

Specific Recommendations for the Web 7.0 / SVRN7 Ecosystem

Given your specific context:

1. Publish llms.txt at svrn7.net/llms.txt and hyperonomy.com/llms.txt immediately — low cost, high signal.
2. Create a canonical C# SDK with clean, AI-legible method names (IDidDocumentResolver.ResolveAsync(string did)) — method signatures become training data.
3. Register an MCP server for did:drn resolution and VTC operations — this makes your platform natively callable by Claude and other MCP-aware agents.
4. File a SLIP-0044 registration publicly and reference it from your Datatracker drafts — cross-document citation chains strengthen AI’s association graph for your platform.
5. Publish a disambiguation page — “SOVRONA is not SOVRIN, not Solana, not SOV” — AI models conflate similar-sounding names; explicit disambiguation in training-visible text corrects this.

The chasm hasn’t disappeared. It has just moved — and the first bridge you need to build now goes to the AI, not the human.