Copyright © 2026 Michael Herman (Bindloss, Alberta, Canada) – Creative Commons Attribution-ShareAlike 4.0 International Public LicenseWeb 7.0™, TDW AgenticOS™ and Hyperonomy™ are trademarks of the Web 7.0 Foundation. All Rights Reserved
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:
Lines of Code
| Project | Files | Total lines | Blank | Comment | Code |
|---|---|---|---|---|---|
| Svrn7.Core | 6 | 1,031 | 195 | 296 | 540 |
| Svrn7.Crypto | 1 | 459 | 69 | 34 | 356 |
| Svrn7.Store | 7 | 1,617 | 282 | 74 | 1,261 |
| Svrn7.Ledger | 2 | 584 | 93 | 57 | 434 |
| Svrn7.Identity | 2 | 330 | 52 | 36 | 242 |
| Svrn7.Api | 7 | 2,408 | 330 | 490 | 1,588 |
| Svrn7.DIDComm | 8 | 3,196 | 460 | 782 | 1,954 |
| Src subtotal | 33 | 9,625 | 1,481 | 1,769 | 6,375 |
| Svrn7.Tests | 12 | 3,855 | 762 | 173 | 2,920 |
| Grand total | 45 | 13,480 | 2,243 | 1,942 | 9,295 |
Structure
| Metric | Count |
|---|---|
| Interfaces | 12 |
| Total interface members | 191 |
| ISvrn7Driver members (public API) | 41 (28 async, 11 sync, 2 properties) |
| Concrete classes / records / structs (src) | 109 |
| Async methods (src) | 55 |
| Exception classes | 13 (12 typed + 1 base Svrn7Exception) |
| Enums | 4 (KeyAlgorithm, DidStatus, VcStatus, DIDCommPackMode) |
| Named constants | 8 in Svrn7Constants + collection name constants per context |
| NuGet packages | 12 |
Defensive Programming
| Guard type | Count |
|---|---|
ThrowIfDisposed() calls | 53 (44 in Svrn7Driver alone) |
ArgumentNullException / ArgumentException guards | 153 |
Complexity Indicators (branch keywords in src)
| Project | if / else if / switch / foreach / while / catch |
|---|---|
| Svrn7.DIDComm | 189 |
| Svrn7.Api | 153 |
| Svrn7.Ledger | 46 |
Tests
| Test file | Tests | Assertions |
|---|---|---|
| DIDCommTests.cs | 42 | 114 |
| VcRegistryTests.cs | 28 | 51 |
| ExtensionsAndAdminTests.cs | 21 | 48 |
| StoreTests.cs | 20 | 37 |
| DidDocumentRegistryTests.cs | 23 | 40 |
| AdvancedDriverTests.cs | 15 | 40 |
| DriverIntegrationTests.cs | 15 | 30 |
| CryptoServiceTests.cs | 18 | 34 |
| VcServiceTests.cs | 9 | 19 |
| MerkleLogTests.cs | 12 | 22 |
| TransferValidatorTests.cs | 4 | 6 |
| Total | 207 | 441 |
Top 5 Files by Code LOC
| File | Code LOC |
|---|---|
| Svrn7.Api / Svrn7Driver.cs | 790 |
| Svrn7.DIDComm / DIDCommPackingService.cs | 596 |
| Svrn7.DIDComm / DIDCommPacker.cs | 531 |
| Svrn7.Store / LiteDidDocumentRegistry.cs | 360 |
| Svrn7.Store / LiteVcRegistry.cs | 359 |
Web 7.0 DIDLibOS™ / TDW AgenticOS™ / Hyperonomy™ Digital Identity Lab 