Parchment Programming: Diagramic Design Document/Intermediate Representation Optimization (Part 2)

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 DILibOS™, TDW AgenticOS™, TDW™, Trusted Digital Web™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved.

This article presents a structured analysis as well as the key optimization dimensions for diagrams used for Parchment Programming.

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

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

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:

2. Annotate All Arrows with Interface Contracts

Every arrow should carry:

• Direction (already present ✓)
• Protocol (partially present ✓)
• C# interface name (missing ✗)

Example additions:

DIDComm Switchboard → DIDComm/HTTP Listener  :  IDIDCommDispatcher
Agent Runspace → Fast Cache                  :  IFastCacheRepository  
LOBE → Runspace Pool                         :  ILoadableExtension
SVRN7 XFER → SQL Server                      :  ISvrn7TransferGateway

3. Declare the .NET Project Boundary Map

Add a legend box (or overlay color coding) mapping diagram regions to .csproj names — this is the single most Claude-actionable addition:

■ Blue region   →  Svrn7.Core
■ Green region  →  Svrn7.Society  (TDA + Runspace Pool)
■ Purple region →  Svrn7.Federation  (DIDComm/HTTP + REST)
■ Yellow region →  Svrn7.Identity  (DID Doc + VC Doc Resolvers)
■ Right panel   →  Svrn7.VTC  (VTC7 federation mesh)
■ Bottom-left   →  Svrn7.Cli

4. Disambiguate the Agent Model

The diagram shows Agent 1/2/3/N but doesn’t specify whether agents are:

• Separate IHostedService instances
• Task-isolated runspaces within one service
• Dynamically loaded plugins

Add a small inset box:

Agent Instantiation Model:
«PluginFactory» AgentRunspaceFactory
  → creates: IAgentRunspace per registered AgentDescriptor
  → lifecycle: Scoped per DIDComm session

5. Annotate Data Store Schema Contracts

Each LiteDB cylinder should carry its C# collection type:

Fast Cache (LiteDB)           →  ILiteCollection<CachedMessage>
Long-Term Message Memory      →  ILiteCollection<MessageRecord>
DID Doc Registry              →  ILiteCollection<DidDocument>
VC Doc Registry               →  ILiteCollection<VcDocument>

6. Add a DIDComm V2 Mode Annotation

Given the pending code change (Authcrypt → SignThenEncrypt), explicitly annotate:

DIDComm V2 (Secure Trusted Messaging)
  Default mode: «SignThenEncrypt»
  Impl: DIDCommService.cs

This makes Claude’s generated code default-correct without needing a separate instruction.

7. Add an Inbound/Outbound Processing Pipeline Spec

The Inbound Processing (Unpack) and Outbound Processing (Pack) labels are present but unpipelined. Add:

Inbound:  HttpRequest → DIDCommHttpListener 
          → Unpack() → DIDCommSwitchboard 
          → Route(agentId) → IAgentRunspace
Outbound: IAgentRunspace → DIDCommSwitchboard 
          → Pack() → REST/HTTP → Internet

This directly generates the middleware pipeline registration in Program.cs.

8. Mark SOVRONA/SVRN7 SRC as a Subsystem Boundary

The POS terminal icon is ambiguous — add:

«ExternalSubsystem» SOVRONA (SVRN7)
  Shared Reserve Currency (SRC)
  Access via: ISvrn7TransferGateway
  Protocol: SVRN7 XFER (SQL/TDS for SQL Server, CIPHER for NEO4J)

Structural Template Claude Needs to See

The ideal ParchmentProgramming diagram for Claude-coded C#/.NET 8 follows this pattern per box:

┌─────────────────────────────┐
│ «stereotype»                │
│ ComponentName               │
│ : InterfaceName             │
│ [ProjectName]               │
│ ─────────────────           │
│ key method / contract hint  │
└─────────────────────────────┘

Even adding stereotype + project name to just the top-level boxes would dramatically improve Claude’s code generation accuracy.

Priority Order for Maximum Claude Utility

1. Project boundary color map — enables correct using and DI registration
2. Interface names on arrows — enables correct abstraction layer
3. Agent instantiation model inset — resolves the biggest structural ambiguity
4. DIDComm default mode annotation — locks in the SignThenEncrypt decision
5. LiteDB collection types — enables correct repository scaffolding
6. Stereotype labels — enables correct C# class/interface/attribute selection

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 1 can be found here: https://hyperonomy.com/2026/04/09/parchment-programming-diagramic-design-document-intermediate-representation-part-1/