ENGINEERING-MATERIALIZATION-VERIFICATION-PRINCIPLE

Engineering-Prinzip – Materialisierung erfordert Verification und Evidence#

Leitsatz#

Eine Änderung ist nicht abgeschlossen, wenn sie umgesetzt wurde. Sie ist abgeschlossen, wenn verifizierbare ⌘EvidenceTechnical documentation artifact. belegt, dass das beabsichtigte Ergebnis erreicht wurde.

Zweck#

Das Prinzip verbindet Architektur, Implementierung und Betrieb zu einem geschlossenen Engineering-Lebenszyklus. Es verhindert, dass Werkzeuge, Migrationen, Deployments oder manuelle Schritte ihren eigenen Erfolg lediglich annehmen.

Verbindlicher Lebenszyklus#

Intent
                → Plan
                → Execute
                → Verify
                → Evidence
                → Report
                → Decision

Intent#

Beschreibt den beabsichtigten fachlichen oder technischen Zielzustand.

Plan#

Ermittelt den Istzustand, die notwendigen Änderungen, Risiken, Voraussetzungen und erwarteten Ergebnisse. Ein Plan darf keine dauerhaften Änderungen ausführen.

Execute#

Materialisiert ausschließlich die im Plan beschriebenen Änderungen. Ausführung und Plan müssen korrelierbar sein.

Verify#

Prüft den tatsächlich erreichten Zustand unabhängig von der bloßen Rückgabe des Execute-Schritts. Verifikation muss das Ergebnis beobachten, nicht nur den Prozessstatus.

Evidence#

Erzeugt maschinenlesbare und menschenverständliche Nachweise. Evidence kann aus Testresultaten, Queries, Health Checks, Prüfsummen, Versionen, Artefaktzahlen oder Audit-Ereignissen bestehen.

Report#

Fasst Plan, Ausführung, Verifikation, Evidence, Abweichungen und offene Maßnahmen zusammen. Geheimnisse dürfen nicht in Reports erscheinen.

Decision#

Bewertet, ob der Schritt akzeptiert, wiederholt, zurückgerollt, manuell geprüft oder abgebrochen wird.

Erfolgsdefinition#

Ein Schritt ist nur erfolgreich, wenn:

1. der Plan gültig war,
2. Execute ohne unkontrollierten Fehler beendet wurde,
3. alle verpflichtenden Verifikationen erfolgreich waren,
4. die erforderliche Evidence erzeugt wurde,
5. der Report den realen Zustand widerspruchsfrei beschreibt.

Ein Exit-Code 0 des Execute-Schritts allein ist kein Erfolgsnachweis.

Anwendungsbereiche#

Das Prinzip gilt mindestens für:

• Bootstrap und Erstinstallation,
• Dependency Checks,
• Datenbank- und Benutzeranlage,
• Schema-Migrationen,
• Seeds und Importe,
• Builds und Packaging,
• Deployment und Updates,
• Health- und Smoke-Checks,
• Roundtrip-Importe,
• Dokumentationsmaterialisierung,
• ⌘PromotionTechnical documentation artifact.,
• Backup und Restore,
• Rollback und Recovery.

Fehler- und Rollback-Regel#

Ein fehlgeschlagenes Verify darf nicht als Warnung verborgen werden. Der Schritt erhält den Zustand verification-failed.

Rollback wird ausgeführt, wenn:

• der Schritt atomar rückführbar ist,
• der Vertrag eine Rollback-Aktion definiert,
• Rollback den Zustand nicht verschlechtert.

Ist automatischer Rollback nicht sicher, muss der Report den Zustand manual-recovery-required ausweisen.

Beziehung zum Verification Model#

Der Verify-Schritt erzeugt Verification Artifacts und Verification Results. Evidence ist der konkrete Nachweis dieser Verifikation. Ein Bootstrap-Check, ein Unit Test und ein Health Check sind unterschiedliche Verification-Kategorien, folgen aber demselben Modell.

Beziehung zum Quality Model#

Quality Goals werden nicht allein durch Deklaration erfüllt. Für jedes relevante Quality Goal müssen geeignete Verification Artifacts und Evidence referenziert werden.

Traceability#

Vision
                → Capability
                → Requirement / Constraint / Quality Goal
                → Materialization Step
                → Verification Artifact
                → Evidence
                → Report
                → Acceptance Decision