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.
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:
Traditional Layer
New AI-Mediated Layer
Innovator humans discover your platform
AI models are trained/fine-tuned on your docs
Early Adopters experiment
AI generates working starter code
Early Majority follows proven patterns
AI recommends your platform confidently
Word-of-mouth spreads
AI’s citations / training data spreads
Chasm: “will the mainstream trust it?”
New chasm: “does the AI know it well enough to generate correct code?”
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)
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)
Agentic AI systems discover tools through registries
OpenAI / Anthropic Custom GPT / Projects
Direct context injection
System prompts for your platform’s AI assistant
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:
Publish llms.txt at svrn7.net/llms.txt and hyperonomy.com/llms.txt immediately — low cost, high signal.
Create a canonical C# SDK with clean, AI-legible method names (IDidDocumentResolver.ResolveAsync(string did)) — method signatures become training data.
Register an MCP server for did:drn resolution and VTC operations — this makes your platform natively callable by Claude and other MCP-aware agents.
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.
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.
NOTE: The first four capbabilities are general decentralized identity infrastructure that any organization could use independently of the monetary layer.
Sovrona (SVRN7™) is the Shared Reserve Currency (SRC) for the Web 7.0 digital ecosystem, implemented as an embeddable .NET 8 library that manages citizen and society wallets, enforces a governance-controlled three-epoch monetary lifecycle, and maintains a cryptographically tamper-evident audit log of all transactions.
Unlike traditional and modern digital currencies, SVRN7 is built on a foundation of self-sovereign identity — every participant is a DID holder, every entitlement/endowment is a Verifiable Credential, and trust between parties is established through standards-based cryptographic proofs rather than a shared blockchain or central authority.
Web 7.0 Use Cases
With configurable DID method names, the library becomes usable in scenarios that have nothing to do with the SVRN7 SRC.
Healthcare network. A hospital consortium where each hospital operates its own DID method (did:hospital-a, did:hospital-b). Patient VCs issued by one hospital are verifiable by any other. The Merkle log provides an auditable record of credential issuance without exposing patient data. DIDComm handles encrypted referral messages between hospitals.
Supply chain. A manufacturing network where each tier-1 supplier owns a DID method. Components carry VC provenance records signed by their manufacturer’s DID. The Federation equivalent is the brand owner who sets the governance rules. The UTXO model tracks component custody rather than currency.
Professional credentialing. A federation of professional bodies (law societies, medical councils, engineering institutes) where each body owns its DID method and issues member credentials. Cross-body credential verification uses the same IDidResolver routing the SVRN7 library already needs.
Government identity federation. Multiple municipal or provincial identity systems where each jurisdiction owns its DID method. Citizens have identities under their jurisdiction’s method. Cross-jurisdiction services verify credentials without requiring a central identity broker.
Q1. What is your internal representation of this solution? …an AST? …the actual source code? …some other modeling approach/metamodel? …used for generating code, documenting the README.md, creating test cases, creating architecture diagrams, etc.
NOTE: The current set of software metrics for this solution-under-development can be found in APPENDIX A.
This is a genuinely interesting question and the honest answer is: there is no persistent internal representation at all. Here is what actually happens:
What I am, mechanically. I am a transformer that maps a context window (a flat sequence of tokens) to a probability distribution over the next token. There is no AST, no object graph, no schema, no database, no symbol table. When this conversation session ends, nothing persists — the weights of the model are fixed and do not change.
What substitutes for a representation. During this conversation, the context window itself is the representation. Every message, every code block, every README excerpt, every test name you have seen scrolling past — all of that is sitting in my active context as raw tokens. When I generated the ArchiMate diagram or the README or the test cases, I was pattern-matching against that token sequence and the statistical regularities in my weights that encode knowledge of C#, ArchiMate OEF XML, W3C VC, DIDComm v2, RFC 6962, etc.
How this produces consistent outputs. The compacted summary at the top of this conversation (the one listing 45 files, 207 tests, all the interface members, all 20 bugs fixed, etc.) is doing the work of an “architecture model.” It was written by me in a previous session to act as a faithful briefing document — a structured natural-language encoding of the project state. When I generate code, tests, a README, or an ArchiMate diagram from it, I am essentially translating that natural-language description through my weights.
What I do not have. I have no:
Parse tree or AST of the C# source
Type graph, dependency graph, or call graph
Formal metamodel instance (no MOF, no Ecore, no ArchiMate metamodel objects)
Semantic index of method signatures
Persistent memory between sessions (the compacted summary was explicitly written to bridge sessions)
What this means for your artefacts. The three outputs — source code, README, tests, and ArchiMate diagram — were all produced from the same token context, so they are coherent with each other in the sense that a careful human author would make them coherent. But they are not derived from a single authoritative model the way a proper MDE (Model-Driven Engineering) toolchain would derive them. If the C# source and the ArchiMate diagram diverge, neither one automatically updates the other — you would need to bring the divergence back into a context window and ask me to reconcile.
The practical implication for Web 7.0. If you want genuine model-driven traceability — where a change to ISvrn7Driver propagates automatically into the ArchiMate model, README, and test stubs — that is a toolchain problem (e.g. Roslyn-based code analysis feeding an ArchiMate metamodel instance in Archi or a Sparx EA repository). I can help design or implement that toolchain, but I am not myself that toolchain.
APPENDIX A – Solution Software Metrics (April 5, 2026)
Here are the complete, live-measured metrics for the SVRN7 v0.5.0 solution:
Great question — and worth thinking through carefully, because the SAE framing maps surprisingly well onto digital agents if you abstract it correctly.
The Core Analogy
In autonomous vehicles, the levels measure how much human oversight and intervention is required for safe operation. The same axis applies to digital agents: how much must a human monitor, correct, or authorize before the agent acts?
A Proposed Digital Agent Autonomy Scale
Level
Name
Agent Behavior
Human Role
0
No Automation
Pure tool, executes only explicit commands
Human does everything
1
Assisted
Suggests actions, autocompletes, drafts
Human approves all outputs
2
Partial
Executes defined tasks autonomously within a session
Human monitors, can interrupt
3
Conditional
Handles multi-step workflows, escalates on ambiguity
Human on standby, notified of exceptions
4
High
Operates across systems within a defined trust domain
Human sets policy, reviews periodically
5
Full
Acts as a sovereign delegate across any context, any system, any time
Human sets intent once; agent governs itself
What Makes Level 5 Hard for Digital Agents
Just like autonomous vehicles, nobody has achieved digital Level 5 yet — and for parallel reasons:
Identity — who authorized this agent to act, and can that be verified in real time by any system it touches?
Integrity — is the agent acting on real, unmanipulated data/context, or has its information environment been poisoned?
Accountability — is every decision cryptographically auditable after the fact?
Trust portability — can the agent’s authorization travel with it across organizational boundaries, jurisdictions, and protocols?
These are almost exactly the same gaps the did:level5 site frames for vehicles — just in a digital context.
Where Web 7.0 Trusted Digital Assistants Fit
Your TDA concept is explicitly designed to be a Level 5 digital agent architecture. The components map directly:
TDA Component
Autonomy Function
Analogy
DID (did:drn, did:7)
Sovereign identity — “who am I, provably?”
did:verifiedcar — identity root
Verifiable Credentials / VTCs
Authorization — “what am I permitted to do?”
Certification gate
Cryptoseals
Integrity — “is this data/document unmanipulated?”
did:viewonwebsite — reality root
PS Runspace Pool / MCP-I/D
Execution environment with bounded authority
Mojo Enclave equivalent
DIDNET7
Trust transport across organizational boundaries
The network substrate
Verifiable Trust Circles
Governance — “who vouches for this agent within this community?”
Root of trust federation
The TDA is essentially a Level 5 digital agent that carries its own sovereign identity, operates within cryptographically governed trust circles, and can act across systems without requiring human re-authorization at each step — while remaining fully auditable.
The Key Distinction from Lower Levels
The leap from Level 4 to Level 5 — for both vehicles and digital agents — is trust portability across unknown contexts. A Level 4 agent can operate autonomously within a known, pre-configured environment. A Level 5 agent can walk into an entirely new system, organization, or jurisdiction and be trusted on first contact because its identity, credentials, and authorization chain are self-contained and cryptographically verifiable.
That’s exactly what did:drn + VTCs + cryptoseals are designed to enable — the agent doesn’t need a prior relationship with the system it’s interacting with. The trust travels with it.
A Possible Contribution
Given your standards work, there may be value in formally proposing a Digital Agent Autonomy Level framework — analogous to SAE J3016 but for agentic AI systems — with Web 7.0 / TDA architecture positioned as the reference implementation for Level 5. It would give the broader field (IETF, W3C, ISO, IEEE) a vocabulary for discussing agent trust requirements at each level, and anchor your work as foundational infrastructure rather than one implementation among many.
Do digital agents need to use AI to be compliant with Level 5 Autonomous Operation?
No — and this is an important distinction worth being precise about.
Level 5 is about autonomy architecture, not AI
In the SAE vehicle context, Level 5 says nothing about how the driving decisions are made — only that the system can handle all conditions without human intervention. The intelligence mechanism is orthogonal to the autonomy level.
The same applies to digital agents. Level 5 is a statement about:
Trust — the agent’s identity and authorization are sovereign and portable
Accountability — every action is cryptographically auditable
Scope — the agent can operate across any context without human re-authorization
Integrity — the agent acts on verified, unmanipulated information
None of those properties require AI. A deterministic rule-based agent, a scripted workflow engine, or a pure cryptographic protocol daemon could in principle satisfy all four.
What AI adds — and doesn’t add
AI (specifically LLMs or reasoning models) adds:
Natural language understanding and generation
Handling of ambiguous or novel situations
Flexible goal decomposition
Adaptability across unanticipated contexts
But AI also complicates Level 5 compliance because:
LLM outputs are non-deterministic — the same input can produce different actions
Reasoning chains are not natively auditable in a cryptographic sense
AI can be manipulated via prompt injection — a direct analogue to the visual injection attack the did:level5 site describes
AI doesn’t inherently carry sovereign identity or verifiable authorization
So paradoxically, AI is the component that most threatens Level 5 compliance if not properly bounded, and the trust architecture — DIDs, VTCs, cryptoseals, runspace governance — is what contains the AI and makes its actions compliant.
The Right Mental Model
Think of it in layers:
Layer
Role
AI Required?
Trust & Identity
DID, VTCs, cryptoseals
No
Authorization
Credential verification, policy enforcement
No
Execution governance
PS Runspace Pool, MCP-I/D boundaries
No
Task intelligence
Reasoning, language, ambiguity handling
Optional
Audit trail
Cryptographic action log
No
AI sits only in the task intelligence layer. All the layers that make an agent Level 5 compliant are below it and independent of it.
For TDA Specifically
A Trusted Digital Assistant could be fully Level 5 compliant running nothing but deterministic logic — scripted workflows, rule engines, protocol handlers — as long as the identity, authorization, integrity, and auditability infrastructure is in place.
When an AI reasoning layer is present, the TDA architecture constrains it: the AI operates within a bounded runspace, its outputs are subject to credential-gated authorization before execution, and its actions are sealed into the audit record. The AI doesn’t grant Level 5 — the architecture does. The AI is a passenger, not the driver.
This is actually a meaningful standards argument: Level 5 digital agent compliance is an infrastructure and governance property, not a capability property. A very capable AI with no trust architecture is not Level 5. A simple deterministic agent with full sovereign identity and cryptographic accountability is.
Pattern:id at the document root is always an identity DID. Every field that contains a fragment — verification methods, verification relationships, service entries — is always a locator DID. controller is always an identity DID. serviceEndpoint values are retrieval URLs, outside the DID identity/locator taxonomy entirely.
Pattern: Top-level id, issuer.id, credentialSubject.id, and any DID references within claims are all identity DIDs — they name entities. credentialStatus.id and proof.verificationMethod are locator DIDs — they navigate to sub-resources. The credentialStatus.id is the one field that often goes unrecognized as a locator but clearly is: it points into a status registry to retrieve the current revocation state of this specific credential.
DIDComm Message
{
"id": "urn:uuid:f81d4fae-7dec-11d0-a765-00a0c91e6bf6", ← IDENTITY (message identity — URN, not DID)
Pattern: DIDComm message fields are overwhelmingly identity DIDs — from, to, from_prior.iss, from_prior.sub, from_prior.aud all name parties, not locations. The message id is typically a URN UUID — an identity token outside the DID space entirely. Locator DIDs appear only when explicitly navigating to a sub-resource — such as a CredentialRegistry service endpoint in an attachment link, or a verification method reference in an attached cryptoseal.
Cross-Document Summary
Field
DID Doc
VC Doc
DIDComm
Document id
Identity
Identity
Identity (URN)
controller
Identity
—
—
issuer / issuer.id
—
Identity
—
credentialSubject.id
—
Identity
—
from / to
—
—
Identity
from_prior.iss / .sub
—
—
Identity
verificationMethod.id
Locator
—
—
Verification relationship refs
Locator
—
—
service.id
Locator
—
—
proof.verificationMethod
—
Locator
—
credentialStatus.id
—
Locator
—
Attachment links with ?service=
—
—
Locator
The governing rule across all three document types is consistent and clean:
A DID with no # or ? is always an identity DID — it names an entity. A DID with # or ? is always a locator DID — it navigates to a sub-resource. This rule holds uniformly across DID Documents, VC Documents, and DIDComm Messages.
This specification defines Web 7.0 Verifiable Trust Circles (VTCs), a generalized mechanism for expressing verifiable multi-party membership, belonging, and trust relationships using the W3C Verifiable Credentials (VC) Data Model 2.0 and VC Data Integrity Proof Sets. VTCs extend the Partof Architecture Reference Model (PARM) — also referred to as the MemberOf or CitizenOf model — to provide a universal credential pattern that subsumes prior pairwise constructs (PHCs, VRCs) and additionally supports voting-based decision making, meeting requests, task forces, and digital societies.
STATUS
This document is derived from community discussion in the Trust over IP Foundation (ToIP) Digital Trust Graph Working Group (DTGWG) Credentials Task Force, GitHub Discussion #8, November–January 2025–2026.
Table of Contents
1. Introduction
2. Terminology and Definitions
3. Design Principles
4. The Partof Architecture Reference Model (PARM)
5. VTC Data Model
6. VTC Proof Set Lifecycle
7. Roles and Participants
8. Use Cases
9. Privacy and Security Considerations
10. Conformance
11. Relationship to Other Specifications
12. References
1. Introduction
The Web 7.0 paradigm seeks to establish a decentralized, agent-centric, privacy-preserving digital society. Central to this vision is the ability of digital entities — people, organizations, autonomous agents — to form verifiable groups: trust circles that are cryptographically provable, privacy-respecting, and composable.
Prior specifications in the Trust over IP (ToIP) ecosystem defined pairwise constructs (Personhood Credentials, PHCs; and Verifiable Relationship Credentials, VRCs) to link pairs of entities. While useful, these constructs are insufficient to describe multi-party group membership, community affiliation, or collective decision-making.
This specification introduces Verifiable Trust Circles (VTCs), which generalize pairwise credentials into an N-party construct using the standard W3C VC Proof Set mechanism. A single VTC credential can represent a self-credential (N=1), a bilateral relationship (N=2), or any multi-member group (N>2), enabling a single, coherent model for all membership-like relationships.
NOTE
Proof Sets are a normative feature of the W3C VC Data Integrity specification and are explicitly designed for scenarios in which the same data needs to be secured by multiple entities. VTCs leverage this mechanism rather than inventing new cryptographic primitives.
1.1 Motivation
The following observations motivate this specification:
PHCs and VRCs both express a form of ‘belonging to’ — they are specializations of the same universal pattern.
The W3C VC Data Model 2.0 already provides Proof Sets as a standard mechanism for multi-party signing.
A single, generalized Web 7.0 Verifiable Trust Circles (VTCs) pattern — grounded in First Principles Thinking — can subsume both constructs and additionally support voting, community membership, digital governance, and inter-network trust.
The SSC 7.0 Metamodel defines three controller layers (Beneficial, Intermediate, Technical) at which VTCs may apply, enabling rich composability.
1.2 Scope
This specification defines:
The VTC data model, including required and optional properties.
The roles of Initiator, Responder(s), and Notary within a VTC.
The lifecycle of a VTC Proof Set, from initial issuance through multi-party endorsement.
Use case profiles: self-credential, bilateral relationship, multi-party group, and voting scenario.
Privacy and security considerations specific to multi-party proof sets.
This specification does not define transport protocols, DID method requirements, or verifiable presentation formats, except where necessary to illustrate the VTC pattern.
2. Terminology and Definitions
The following terms are used throughout this specification. Unless stated otherwise, terms have the meanings assigned in the W3C Verifiable Credentials Data Model 2.0 [VC-DATA-MODEL].
Verifiable Trust Circle (VTC)
A Verifiable Credential whose credential subject identifies a multi-party trust relationship, and whose proof property contains a Proof Set with one proof contribution per participating member, plus the Notary’s initial proof.
Web 7.0 Verifiable Trust Circles (VTCs)
The generalised name for the VTC pattern when applied to the broader class of MemberOf, PartOf, and CitizenOf relationships. A VTC is a UMC.
Proof Set
As defined in W3C VC Data Integrity [VC-DATA-INTEGRITY], a set of proofs attached to a single secured document where the order of proofs does not matter. Each proof is contributed by a distinct signer.
Initiator (A)
The entity that proposes or originates a VTC. Identified by a DID. Corresponds to the ‘from’ role in VTC credential subject properties.
Responder (B, …, Z)
One or more entities that accept membership in a VTC by contributing their cryptographic proof to the Proof Set. Identified by DIDs. Corresponds to entries in the ‘to’ array.
Notary (N)
A trusted third party — trusted by both Initiator and all Responders — that issues the initial credential shell and contributes the first proof. The Notary is assigned to the VC ‘issuer’ role. In some use cases the Notary MAY be the Initiator or a Responder, provided they play both roles distinctly.
PARM
Partof Architecture Reference Model. The universal pattern underlying VTCs, encompassing MemberOf, CitizenOf, and PartOf relationships.
SSC 7.0 Metamodel
Self-Sovereign Control 7.0 Metamodel. Defines three controller layers — Beneficial Controller, Intermediate Controller (Agent), and Technical Controller (Agent) — at which VTCs may be anchored.
DTG
Digital Trust Graph. A graph of trust relationships between entities, each edge of which may be represented by a VTC.
PHC
Personhood Credential. A pairwise credential representing proof of personhood; a degenerate VTC where N=1.
VRC
Verifiable Relationship Credential. A pairwise credential representing a bilateral relationship; a degenerate VTC where N=2.
DID
Decentralized Identifier, as defined in [DID-CORE].
3. Design Principles
This specification adheres to the following design principles, consistent with the ToIP DTGWG Design Principles [DTGWG-DESIGN]:
3.1 As Simple As Possible But No Simpler
VTCs are grounded in existing W3C VC standards. No new cryptographic primitives or credential types are defined. The only structural addition is the deliberate use of the proof array (Proof Set) to carry per-member proofs alongside the Notary proof.
3.2 First Principles Thinking
PHCs and VRCs are recognized as specializations of a single underlying relationship pattern (PARM). Rather than defining multiple credential types for essentially the same concept, this specification derives one universal type that covers all cases by varying the cardinality of the ‘to’ array and the composition of the Proof Set.
3.3 Privacy by Design
VTC credential subjects SHOULD use confidentialSubject semantics wherever selective disclosure is required. Members of a VTC should be able to prove membership to a verifier without unnecessarily revealing the full membership list. Zero-Knowledge Proof (ZKP) integration in Proof Sets is explicitly supported and encouraged.
3.4 Composability
VTCs compose at each layer of the SSC 7.0 Metamodel. A VTC at the Beneficial Controller layer expresses human-level trust relationships; one at the Intermediate Agent layer expresses agent-level relationships; one at the Technical Controller layer expresses device/key-level relationships.
3.5 Cross-Network Trust
The PARM model is network-agnostic. The same VTC pattern supports trust relationships across and between independent, distinct networks and ecosystems.
4. The Partof Architecture Reference Model (PARM)
The Partof Architecture Reference Model (PARM) provides the conceptual foundation for VTCs. It observes that a large class of real-world relationships — membership, citizenship, parthood, employment, participation — share a common logical structure:
Relationship Type
Example
MemberOf
Alice is a member of the Working Group Trust Circle.
PartOf
Bob is part of the study group.
CitizenOf
Carol is a citizen of the Digital Nation State of Sovronia.
EmployeeOf
Dave is an employee of Acme Corp (DID-identified).
ParticipantOf
Eve is a participant of the 09:00 meeting (a VC-based meeting request).
VoterFor
Frank has cast a vote for Candidate 1 by contributing his proof to that VTC.
All of these reduce to the same credential structure: a VC whose credentialSubject.id identifies the group or decision entity (the ‘circle’), and whose proof array contains proofs from the Notary and each member who has accepted membership. PHCs and VRCs are degenerate cases of this pattern with N=1 and N=2 respectively.
5. VTC Data Model
5.1 Overview
A VTC is a valid W3C Verifiable Credential [VC-DATA-MODEL] with the following structural characteristics:
The issuer property identifies the Notary (N).
The credentialSubject (or confidentialSubject) object includes from, to, and optionally metadata properties that identify the Initiator, Responders, and relationship metadata respectively.
The credentialSubject.id identifies the relationship or group itself, expressed as a DID.
The proof property is an array (Proof Set), containing one proof per signer, ordered as: Notary first, then Initiator, then Responders.
5.2 Minimal Pairwise VTC (N=2, Alice and Bob)
The following non-normative example illustrates a bilateral VTC between Alice (Initiator) and Bob (Responder), notarised by a Notary entity:
For groups with more than two members, the to array is extended to include all Responders, and the proof array gains one additional entry per additional Responder:
When to contains only the Initiator’s own DID, or when from and credentialSubject.id are the same entity, the VTC degenerates to a Personhood Credential (PHC):
For a voting scenario, one VTC is created per candidate. Voters cast their vote by contributing their individual proof to the VTC of the candidate they support. The vote count is the number of valid member proofs in the Proof Set.
The to array MAY be populated in advance with eligible voter DIDs, or it MAY be left empty and populated as votes are cast, depending on the election policy and privacy requirements.
5.6 Properties Reference
Property
Req.
Description
id
REQUIRED
DID identifying the VTC credential itself. SHOULD use did:envelope or equivalent.
type
REQUIRED
MUST include ‘VerifiableCredential’ and ‘VerifiableTrustCircle’.
issuer
REQUIRED
DID of the Notary (N). The Notary MUST be trusted by all members.
credentialSubject.id
REQUIRED
DID identifying the relationship or group itself. This is C in the PARM model.
credentialSubject.from
REQUIRED
DID of the Initiator (A).
credentialSubject.to
REQUIRED
Array of DIDs of Responders. MAY be empty for open voting VTCs. MAY include the Initiator’s DID.
credentialSubject.metadata
OPTIONAL
Arbitrary structured metadata about the relationship (label, policy, expiry, etc.).
proof
REQUIRED
Array of proof objects (Proof Set). First proof MUST be from the Notary. Subsequent proofs are from Initiator then Responders in any order.
proof[].id
REQUIRED
DID of the signer contributing this proof entry.
6. VTC Proof Set Lifecycle
The VTC Proof Set lifecycle consists of the following phases. At each phase t, the VTC applies to the Notary and the first t members who have contributed their proof.
Phase 0 — Null VTC
The credential shell is created by the Notary with an empty or pre-populated to array. The Notary contributes the initial proof. No member relationships are yet verified. t = 0.
Phase 1..t — Progressive Endorsement
Each Responder, in any order, reviews the credential and — if they consent to membership — adds their individual proof to the existing Proof Set using the ‘add-proof-set-chain’ algorithm defined in [VC-DATA-INTEGRITY]. The VTC becomes valid for those t members who have signed. Non-signing members are not yet bound.
Phase N — Complete VTC
All Responders listed in the to array have contributed their proofs. The VTC is fully executed and represents a complete, verifiable, multi-party trust relationship.
NOTE
Partial VTCs (0 < t < N) are valid credentials representing the subset of relationships established so far. Verifiers MUST check which proofs are present before asserting full circle membership.
6.1 Adding a Proof
To add a proof to an existing secured VTC, implementors MUST follow the algorithm specified in W3C VC Data Integrity [VC-DATA-INTEGRITY], Section ‘add-proof-set-chain’. The proof is appended to the existing proof array without modifying prior proofs.
6.2 Proof Ordering
Proof Sets are unordered by definition. However, this specification RECOMMENDS the following conventional ordering for readability and auditability: (1) Notary proof, (2) Initiator proof, (3) Responder proofs in the same order as the to array.
7. Roles and Participants
7.1 Notary (N) — Issuer
The Notary is the credential issuer. It MUST be trusted by both the Initiator and all Responders. The Notary is responsible for creating the credential shell, pre-populating the to array (or defining the voting policy), and contributing the first proof. In some use cases, the Notary MAY be the same entity as the Initiator or a Responder, provided that entity plays each role distinctly and the resulting credential satisfies all REQUIRED properties.
7.2 Initiator (A) — From
The Initiator proposes the trust circle. The Initiator’s DID appears in credentialSubject.from. The Initiator contributes a proof to the Proof Set to signify their acceptance of the relationship.
7.3 Responders (B … Z) — To
Each Responder is identified in the credentialSubject.to array. A Responder accepts membership by contributing their individual proof. A Responder who does not contribute a proof is proposed but not yet a verified member.
RULE
The cardinality t of verified members at any time equals the number of valid member proofs (excluding the Notary proof) present in the Proof Set.
8. Use Cases
8.1 Bilateral Trust Relationship (VRC Equivalent)
Alice and Bob wish to establish a verifiable bilateral trust relationship. A Notary (mutually trusted) issues a VTC with from = Alice and to = [Bob]. Both Alice and Bob contribute proofs. The result is a two-party VTC that is equivalent to a classic VRC.
8.2 Personhood Credential (PHC Equivalent)
Alice wishes to create a self-signed personhood credential. A Notary issues a VTC with from = Alice and to = [Alice]. Alice contributes her proof. The result is a one-party VTC equivalent to a PHC.
8.3 Working Group or Task Force
A task force of N participants is formed. A Notary (the WG chair or a community DID) issues a VTC with from = chair and to = [member1, …, memberN]. Members join by contributing their proofs. The VTC provides a cryptographically verifiable roster.
8.4 VC-Based Meeting Request
An organiser issues a VTC with credentialSubject.id = the meeting DID, from = organiser, and to = [attendee1, …, attendeeN]. Attendees RSVP by contributing their proofs. Attendance at the meeting is verifiable from the Proof Set.
8.5 Voting-Based Decision Making
One VTC per candidate is issued by an election official (Notary). Eligible voters cast their vote by contributing their individual proof to the VTC of their chosen candidate. Vote tallying is performed by counting the number of valid member proofs in each candidate’s VTC. This supports maximum flexibility in vote-counting policies (simple majority, ranked-choice, threshold).
8.6 Verifiable Decentralised Registry (VDR)
VC-based voting can be applied to implement a VC-based Verifiable Data Registry (VDR). Append operations to a distributed registry are authorised through a VTC whose members are the registry trustees.
8.7 Digital Society / Digital Nation State
A digital society (e.g. a digital religion, community, or nation state) is defined by a VTC whose members are the citizens. Governance operations — electing trustees, passing resolutions — are performed through subsidiary voting VTCs.
9. Privacy and Security Considerations
9.1 Selective Disclosure
Implementations are STRONGLY RECOMMENDED to use confidentialSubject semantics and selective disclosure proof mechanisms (e.g. BBS+ signatures) to allow individual members to prove their membership in a VTC without revealing the full membership list or metadata.
9.2 ZKP Integration
The Proof Set mechanism is compatible with zero-knowledge proof (ZKP) contributions. A member MAY contribute a ZKP as their proof entry, revealing only that they meet the membership criteria without revealing their DID. Implementations SHOULD define a profile for ZKP-based proof entries.
9.3 Privacy Budget and Reconstruction Ceiling
When multiple agents controlled by one First Person contribute to a shared VTC, care must be taken to ensure that the combined disclosure across proof entries does not exceed the privacy budget of the First Person. The reconstruction ceiling — the probability that an observer can reconstruct the First Person’s identity from the combined proof data — MUST be maintained below the threshold defined by the applicable trust framework.
NOTE
This consideration was raised during community discussion in the context of internal VTCs and the Trust Spanning Protocol (TSP) between two agents controlled by one First Person.
9.4 Notary Trust
The Notary (issuer) occupies a privileged position: it issues the credential shell and contributes the first proof. Verifiers MUST independently verify that the Notary is trusted by all relevant parties. The Notary SHOULD be a well-known, community-governed DID with transparent governance.
9.5 Voting Integrity
For voting VTCs, the following security properties MUST be considered: (1) eligibility — only eligible voters can contribute proofs; (2) anonymity — voter DIDs SHOULD be anonymised or pseudonymised; (3) non-repudiation — each proof is cryptographically bound to the voter’s key; (4) single-vote enforcement — the to array or the Notary’s policy SHOULD prevent duplicate proof contributions from the same voter DID.
10. Conformance
A conforming VTC implementation:
MUST produce VTC credentials that are valid W3C Verifiable Credentials conforming to [VC-DATA-MODEL].
MUST use a proof array (Proof Set) as defined in [VC-DATA-INTEGRITY].
MUST include the issuer property identifying the Notary.
MUST include credentialSubject.id, credentialSubject.from, and credentialSubject.to.
MUST use the ‘add-proof-set-chain’ algorithm from [VC-DATA-INTEGRITY] when adding proofs incrementally.
SHOULD include ‘VerifiableTrustCircle’ in the type array.
SHOULD implement selective disclosure mechanisms for credentialSubject properties.
MAY extend the credentialSubject.metadata property with domain-specific claims.
11. Relationship to Other Specifications
11.1 W3C VC Data Model 2.0
VTCs are valid W3C Verifiable Credentials. All normative requirements of [VC-DATA-MODEL] apply. VTCs use the issuer and credentialSubject properties as defined therein.
11.2 W3C VC Data Integrity
VTCs rely on the Proof Set mechanism defined in [VC-DATA-INTEGRITY], specifically the ‘add-proof-set-chain’ algorithm for incremental proof contributions.
11.3 ToIP DTGWG Design Principles
This specification is consistent with the ToIP DTGWG Design Principles [DTGWG-DESIGN] and the DTG-ZKP Requirements [DTGWG-ZKP].
11.4 SSC 7.0 Metamodel
VTCs integrate with the Self-Sovereign Control 7.0 Metamodel [SSC-7]. VTCs may be anchored at the Beneficial Controller, Intermediate Controller, or Technical Controller layer.
11.5 Trust Spanning Protocol (TSP)
VTCs are compatible with the Trust Spanning Protocol [TSP] as a credential format for expressing channel-level membership and authorization relationships.
This specification was derived from community discussion contributions by: Michael Herman (mwherman2000), @talltree, @adamstallard, @mitchuski, @peacekeeper, @GraceRachmany, and other participants of the Trust over IP Foundation DTGWG Credentials Task Force. The editors gratefully acknowledge all contributors to GitHub Discussion #8.
14. Appendix A: Web 7.0 DIDLibOS Architecture Reference Model (DIDLibOS-ARM)
Web 7.0 Pando™ / Consort DSL™ / Hyperonomy™ Digital Identity Lab 