DS09 — The FES Envelope Report

Trigger S3, Continuation

The project/purchase contract with PARTNER-1 is concluded via an FES service (placeholder FES-PROVIDER, DocuSign-like). The classic practice: the envelope lives in the provider's cloud; an email confirmation lands in the mailbox. Evidence gaps guaranteed.

GitCover hooks in: The Envelope Report documents the process repo-natively — as a JSON artifact with all the metadata the service provides.

The Envelope Structure

{
  "$schema": "https://gitcover.org/schemas/fes-envelope-1.0.schema.json",
  "uuidV7": "<deterministische uuidV7>",
  "type": "fes-envelope-report",
  "envelope_id": "ENV-EXAMPLE-0001-XXXX-XXXX-XXXXXXXXXXXX",
  "provider": {
    "name": "FES-PROVIDER",
    "service": "DocuSign-artig",
    "report_source": "Web-UI-Export / API"
  },
  "matter": {
    "title": "Trademark and Domain Purchase and Transfer Agreement",
    "contract_date": "2026-08-24",
    "ur_doc_ref": {
      "kind": "external-doc",
      "note": "Vertrag als PDF beim Dienst; Quell-Dokument-SHA im Report verankert",
      "sha256": "7a054fa53ef6ec09053fc925d264ca0a8b7c140ff49e157fef393257d476272b"
    }
  },
  "signers": [
    {
      "name": "Erich Mustermann",
      "role": "Seller (Verkäufer)",
      "entity": "E1 (natürliche Person)",
      "status": "signed",
      "signed_at": "2026-08-24T14:12:00Z",
      "cert_fingerprint": "…",
      "auth_method": "provider-identity-check"
    },
    {
      "name": "PARTNER-1 (PARTNER-2)",
      "role": "Purchaser (Käufer)",
      "entity": "PARTNER-2 (Platzhalter: Vertragspartner-Sitz, EU-Ausland)",
      "status": "signed",
      "signed_at": "2026-08-24T14:15:00Z",
      "cert_fingerprint": "…",
      "auth_method": "provider-identity-check"
    }
  ],
  "documents": [
    {
      "kind": "contract-pdf",
      "filename": "contract-agreement-signed.pdf",
      "sha256": "7a054fa53ef6ec09053fc925d264ca0a8b7c140ff49e157fef393257d476272b",
      "pages": 12,
      "signature_format": "[PAdES](../../glossar.html#pades "PDF Advanced Electronic Signature — Glossar")-B-T"
    },
    {
      "kind": "certificate-of-completion",
      "filename": "DocuSign_Certificate-of-Completion.pdf",
      "sha256": "…",
      "note": "Dienst-Report (Sicht der Plattform)"
    }
  ],
  "timeline": [
    {"event": "envelope-created", "at": "2026-08-22T09:00:00Z"},
    {"event": "sent-to-signers", "at": "2026-08-22T09:05:00Z"},
    {"event": "signed", "by": "Seller", "at": "2026-08-24T14:12:00Z"},
    {"event": "signed", "by": "Purchaser", "at": "2026-08-24T14:15:00Z"},
    {"event": "completed", "at": "2026-08-24T14:15:30Z"}
  ],
  "verification": {
    "method": "sha256-Verifikation der PDFs + pdfsig-Prüfung der Signatur",
    "verified_at": "2026-09-13T16:30:00Z",
    "verified_by": "E1"
  }
}

Why the Report Belongs in the Repo

Three evidentiary reasons:

Independence from the service — the Envelope Report exists even if the provider changes or discontinues its portal. The metadata (envelope ID, signers, timestamps, hashes) are independently verifiable.
Chaining with the repo chain — the report links via SHA-256 to the source document version and the signature doc (Part I); the verification routine (DS04) covers the FES part as well.
GoBD/AO document chain — the report is an incoming document (with sidecar .v7g.md, V7GUID cataloging); the signed PDF is the original document. Both go into the GCPN container (DS05) or the container package (DS10).

Sidecar Cataloging

The Envelope Report receives a sidecar (.v7g.md) with an FES class taxonomy:

Class	Meaning
`FES_ENVELOPE_REPORT`	The report itself (JSON)
`FES_SIGNED_DOCUMENT`	The signed PDF (original document)
`FES_CERTIFICATE_OF_COMPLETION`	Service report (platform's view)

All three are promote candidates for the OSS Normative Root.

The Report in the GCPN Container

The container (DS05) extends its artifacts list:

{
  "role": "fes-envelope-report",
  "kind": "json",
  "location": "260913_fes-envelope-report.json",
  "sha256": "<SHA-256>",
  "sidecar": "260913_fes-envelope-report.json.v7g.md"
},
{
  "role": "fes-signed-document",
  "kind": "pdf",
  "location": "contract-agreement-signed.pdf",
  "sha256": "7a054fa5…272b",
  "note": "physisch im Container-Paket (DS10)"
}

Practical Finding: An Example Case (Anonymized)

The saga becomes concrete in an example case (placeholder): purchase contract (initiation → FES envelope ENV-EXAMPLE-0001… → signing → payment → delivery → completion), handled exactly according to this pattern — Envelope Report, signed PDF (SHA-256 anchored), Certificate-of-Completion and the follow-up documents are in the repo and form the gapless chain: initiation → signing → payment → delivery → completion. All names, IDs, and dates are placeholders; the structure is the lesson.

Summary

The Envelope Report documents the FES process repo-natively — independent of the service, chained with the text form chain, GoBD-compliant.
The three FES classes (FES_ENVELOPE_REPORT, FES_SIGNED_DOCUMENT, FES_CERTIFICATE_OF_COMPLETION) catalog the artifacts.
Next article (DS10): the container package — the physical delivery of the entire chain.

Created: 260913 | Part II, Article DS09 | Series: digital-signage