How does Parchment Programming (PPML) help solve the Discontinuous Code Transformation (DCT) problem?

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

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

Here is how Parchment Programming addresses the Discontinuous Code Transformation problem, described in the following two articles:

The Code Discontinuous Transformation Problem 0.1

The Code Discontinuous Transformation Problem 0.2

The Core Diagnosis

The DCT problem 0.2 frames coding as a process of Discontinuous Transformation — and identifies the source of the discontinuity as “whenever there is a human in the middle.” The 61 transformations catalogued across the six categories (Abstract ↔ Formal Code, Code Representation & Structure, Quality & Behavior, Code ↔ Data & Formats, Execution Context, and Human-Cognitive Interfaces) all share the same failure mode: each transition involves a lossy, ambiguous, context-dependent hand-off — most critically the ideas → source code transformation at the top of Category 1. The human is the discontinuity.

Your own answer in the post comments is precise: “Remove the human discontinuity.” Parchment Programming is the methodology for doing exactly that.

How Parchment Programming Removes the Discontinuity

Parchment Programming is an architecture-first software development methodology where a richly annotated visual diagram — the “parchment” — serves as the primary design document and intermediate representation (IR) that an AI coding assistant reads directly to generate correct, idiomatic code. Rather than translating requirements through layers of prose specifications, the diagram itself encodes stereotypes, interface contracts, project boundaries, data models, and protocol annotations in a form that is simultaneously human-readable and AI-actionable.

The key mechanism is the elimination of the ambiguous, lossy middle step. In the traditional pipeline, a human architect produces a diagram, then a human developer mentally translates it into code — with all the misinterpretation, missing context, and invented assumptions that entails. Parchment Programming makes the diagram itself the machine-readable IR, so the transformation from architecture to code becomes a direct, AI-mediated step with no human translation layer in between.

The PARCHMENT.md as a Continuous Transformation Surface

The PARCHMENT.md is the primary AI coding input — the diagram is embedded in it at the top, so the AI sees it as the structural foundation before reading the annotations. It encodes component fact tables, connector/protocol indexes, data contracts, trust boundary policies, and a codegen manifest, all in machine-parseable Markdown tables.

This structure directly addresses the DCT categories:

• Category 1 (Abstract ↔ Formal Code): The diagram + PARCHMENT.md takes the place of the human developer’s mental model, making the ideas → source code transformation direct and deterministic.
• Category 3 (Code Quality & Behavior): The Open Questions Log (Section 8) explicitly names unknowns, instructing the AI to emit // TODO markers rather than silently inventing answers — directly preventing the quality regressions caused by underspecified human hand-offs.
• Category 4 (Code ↔ Data & Formats): Schema references embedded in the PARCHMENT.md (e.g., schemas/didcomm-envelope.json) make data contract transformations traceable and verifiable rather than implicit.

The Clean Separation of Concerns

The diagram handles spatial/structural truth; the companion PARCHMENT.md handles behavioral/contractual truth. This is a deliberate architectural choice that mirrors how compilers separate parse trees (structural) from semantic analysis (behavioral) — again reducing human interpretive variability at each stage.

Bottom Line

The DCT problem is essentially a problem of lossy intermediate representations wherever a human serves as the translation layer. Parchment Programming solves it by making the architecture diagram itself the lossless, AI-readable intermediate representation — replacing the human-as-translator with an AI-as-transformer operating on a richly structured artifact. The result is that the most expensive and error-prone DCT transition — ideas → source code — becomes a well-specified, reproducible, AI-mediated step rather than a creative act dependent on individual developer interpretation.