DS09 — Der FES-Envelope-Report

Auslöser S3, Fortsetzung

Der Projekt-/Kaufvertrag mit PARTNER-1 wird über einen FES-Dienst (Platzhalter FES-PROVIDER, DocuSign-artig) geschlossen. Die klassische Praxis: Der Envelope lebt in der Cloud des Anbieters; eine Mail-Bestätigung wandert ins Postfach. Nachweisbrüche garantiert.

GitCover dockt an: Der Envelope-Report dokumentiert den Vorgang repo-nativ — als JSON-Artefakt mit allen Metadaten, die der Dienst liefert.

Die Envelope-Struktur

{
  "$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"
  }
}

Warum der Report ins Repo gehört

Drei Nachweisgründe:

Unabhängigkeit vom Dienst — der Envelope-Report existiert auch dann, wenn der Anbieter sein Portal ändert oder einstellt. Die Metadaten (Envelope-ID, Zeichner, Zeitpunkte, Hashes) sind eigenständig verifizierbar.
Verkettung mit der Repo-Kette — der Report verknüpft per SHA-256 an die Quell-Dokument-Fassung und den Signatur-Doc (Teil I); die Verifikations- routine (DS04) deckt den FES-Teil mit ab.
GoBD/AO-Belegkette — der Report ist ein Eingangsbeleg (mit Sidecar .v7g.md, V7GUID-Katalogisierung); das signierte PDF ist der Originalbeleg. Beide wandern in den GCPN-Container (DS05) bzw. das Container-Paket (DS10).

Sidecar-Katalogisierung

Der Envelope-Report erhält ein Sidecar (.v7g.md) mit einer FES-Klasse-Taxonomy:

Class	Bedeutung
`FES_ENVELOPE_REPORT`	Der Report selbst (JSON)
`FES_SIGNED_DOCUMENT`	Das signierte PDF (Originalbeleg)
`FES_CERTIFICATE_OF_COMPLETION`	Dienst-Report (Sicht der Plattform)

Alle drei sind Promote-Kandidaten für den OSS-Normative-Root.

Der Report im GCPN-Container

Der Container (DS05) erweitert seine artifacts-Liste:

{
  "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)"
}

Praxis-Befund: Ein Beispiel-Vorgang (anonymisiert)

Die Saga konkretisiert sich an einem Beispiel-Vorgang (Platzhalter): Kaufvertrag (Anbahnung → FES-Envelope ENV-EXAMPLE-0001… → Unterzeichnung → Zahlung → Lieferung → Abschluss), abgewickelt genau nach diesem Muster — Envelope-Report, signiertes PDF (SHA-256 verankert), Certificate-of-Completion und die Folge-Dokumente liegen im Repo und bilden die lückenlose Kette: Anbahnung → Unterzeichnung → Zahlung → Lieferung → Abschluss. Alle Namen, IDs und Daten sind Platzhalter; die Struktur ist das Lehrstück.

Zusammenfassung

Der Envelope-Report dokumentiert den FES-Vorgang repo-nativ — unabhängig vom Dienst, verkettet mit der Textform-Kette, GoBD-fähig.
Die drei FES-Klassen (FES_ENVELOPE_REPORT, FES_SIGNED_DOCUMENT, FES_CERTIFICATE_OF_COMPLETION) katalogisieren die Artefakte.
Nächster Artikel (DS10): das Container-Paket — die physische Auslieferung der gesamten Kette.

Erstellt: 260913 | Teil II, Artikel DS09 | Serie: digital-signage