Re: FW: VC-if-eye a plain old .JPG file [was: Binding credentials to publicly accessible repositories]

Michael,
Your PINC <https://share.google/aimode/mt3UfoPjvqyIg5gY3> is directly
relevant prior art. The Archive implements the discipline of assembling
software from a library of verified, interface-conforming components, now
applying this to LLM-generated code using VCs as the attestation mechanism.
That the idea was sound in the early 80s and is sound now is reassuring
rather than surprising.

On multiple implementations of a single interface: yes, exactly. A Form is
an abstract contract—the definition of the `Sort()` interface you
suggested—and multiple implementations can conform to it. A Python
implementation, a Rust implementation, and a Go implementation of the same
rate-limiting contract are all the same Form with different conforming
evaluators. Each implementation carries its own content hash and its own
VC; the Form identity remains stable across all of them.

On “a single file per function”: the annotation model already gives you
this. The source file contains both the function and its VC comment
block—one file, function and annotation together. Two artifacts do not need
to be maintained separately because the annotation lives in the source.

However, the "one file per function" approach becomes cumbersome the moment
you move beyond programming source code. A legal contract assembled from
fifty verified clauses does not want fifty separate VC files—nor does it
want the VC embedded and always visible in the output contract. The right
model there is document comments, exactly as Word and Google Docs handle
tracked changes and annotations: the provenance tags are attached to
specific passages, separately stored, and toggled visible or invisible
depending on whether the reader wants to see them. The W3C Web Annotation
standard was designed precisely for this—structured, addressable
annotations attached to portions of a document without modifying the
document itself, separately storable, queryable, and renderable on demand.
For document-oriented applications, W3C Annotations are likely the right
carrier for provenance attestations, playing the same role that VC comment
blocks play in source code.

Your just-in-time compositor idea is interesting. An LLM directed to
assemble a WebFinger server, a contract, or a diagnostic report from
verified components is already performing composition. Making that process
explicit as a reproducible build step, with the materialised artifact
carrying provenance annotations throughout, is a natural evolution. Whether
you keep the materialised artifact for auditing or discard it after
compilation or execution is a deployment choice, not an architectural one.

bob wyman

On Thu, Apr 2, 2026 at 10:03 AM Michael Herman (Trusted Digital Web) <
mwherman@parallelspace.net> wrote:

> I wrote a similar tool in the early 80s called:
> PINC: A Tool for Maintaining Configurable Software in Pascal
> https://share.google/aimode/mt3UfoPjvqyIg5gY3
>
> In addition to Verifiable-Certified (V-C) functions, you can also support
> multiple alternative V-C implementations of a V-C interface or functional
> specification. For example, different sorting algorithms that share a V-C
> Sort() interface.
>
> A V-C embedded in a VC is easily supported using a GitHub repository, for
> example. A VC document registry can be virtually any content store. It's
> easier to maintain a single file per function than two.
>
> Build yourself a just-in-time V-C source code compositer.  When fully
> materialized, you can through the composited code project away once it is
> compiled or keep it around for debugging.
>
> Michael Herman
> Web 7.0
>
>