Rückmeldung OZMAI zu Monitoring-Resonanz — und was sie für die In-/Outbox-Planung heißt

Thema: Planung der In-/Outbox (Inbox hoch/gehasht/antwortlos, Outbox runter/LED, Zero ohne VPN)
Datum: 2026-09-29
Bezug: 2026-09-28_TLS-GATE-V2-PASSKANTEN-UND-MONITORING-RESONANZ_BRANKO.md (Fragen) und 2026-09-28_ANTWORT-MONITORING-RESONANZ-ZERO-LOKAL_ANSIBLEKATZE.md (Tendenzen, Stand 344b7f4)

Provenienz

Teil A ist ein Text, den Branko eingefügt hat; die Herkunft „OZMAI" ist Brankos Angabe und wurde von der Ansiblekatze nicht selbst geprüft. Er ist unverändert übernommen. Teil B schreibt die Ansiblekatze, dort sind Tendenz und Beleg getrennt ausgewiesen. Nichts hier ist Brain-Kanon, die Ablage gibt keine Autorität (siehe 00_README_AND_RULES.md §0).

Teil A — Rückmeldung (Wortlaut, wie eingefügt)

Branko ❤️ der TLS-Gate-Fall trägt als Prüffall sehr gut – gerade weil er an ein paar Stellen selbst wieder stärker formuliert als das unmittelbar geprüfte Prädikat. Das ist für uns eher Feature als Fehler.

Zu den vier Monitoringfragen haben wir zwei wichtige Korrekturen:

Ein einzelner Monitoringlauf passt wahrscheinlich bereits in den bestehenden VerificationAttempt. Für wiederholte Läufe brauchen wir aber nicht vorschnell eine neue check_definition_id: gleiche Record-ID ⇏ gleiche Semantik. Vergleichbarkeit hängt an Ziel, Prädikat, Mechanismus, Policy und relevanten Annahmen.

Wiederholung ⇏ unabhängige Korroboration heißt außerdem nicht „nur Zustandswechsel speichern“. Wiederholte Checks können zeitliche Abdeckung/Freshness tragen. Transition-only wäre deshalb eine eigene Speicherentscheidung, kein Resultat aus §7.

Selbstmeldung und Außenbeobachtung müssen ihre Herkunft behalten und vergleichbar sein – sie müssen dafür aber nicht im selben Store oder derselben Tabelle liegen:
same store ⇏ common basis
separate store ⇏ non-comparable
Die gemeinsame Bezugsgrundlage ist semantisch, nicht physisch.

Beim Vektor sind wir nah beieinander: similarity score ⇏ admissibility. Wo die Zulässigkeitsprüfung technisch sitzt, lassen wir noch offen; nur im Score allein darf sie nicht liegen.

Beim Zero ohne VPN trägt self-report ⇏ external observation. Aber append-only JSONL → nach Stromausfall höchstens letzter Übergang weg würden wir ohne fsync-/Filesystem-/Recovery-Beleg nicht behaupten. Ebenso ist lokale Zeit nicht „kein Anker“, sondern zunächst nur locally reported time ⇏ externally verified time.

Und ein schöner Meta-Gegendruck auf TLS-Gate selbst: TOTP_VALID, DNS-01 und Audit-Attribution sind in deinem Text teilweise schon wieder stärker formuliert als das unmittelbar geprüfte Prädikat. Genau das sollten wir als Prüffälle behalten. 🌲🦉

Teil B — Einordnung für die In-/Outbox (Ansiblekatze)

B1. Was sich an der eigenen Antwort vom 09-28 ändert

Aussage in der Antwort vom 09-28	Stand nach der Rückmeldung
Frage 1: wiederholte Läufe brauchen eine stabile Check-Definition-ID	Zurückgenommen. Die ID trägt keine Semantik. Vergleichbar wird über Ziel, Prädikat, Mechanismus, Policy, Annahmen. Ob und wo diese fünf als Felder oder als Verweis auftauchen, ist offen (⬜).
Frage 2: „Übergänge statt Läufe" als Anwendung von §7, kein neuer Vertrag	Korrigiert. Wiederholung trägt Freshness. Transition-only ist eine eigene Speicherentscheidung und muss als solche benannt werden (⬜).
Frage 3: „im selben Bestand, sonst ist der Relais-Test unmöglich"	Korrigiert. Die Herkunftsmarke bleibt Pflicht, aber die gemeinsame Grundlage ist semantisch. Getrennte Bestände sind nicht per se unvergleichbar.
Frage 4 / Vektor: Zulässigkeit an der Generierungs-/Passkante	Nur halb bestätigt. „Nicht im Score allein" trägt. Die technische Verortung ist bei OZMAI noch offen; die Antwort vom 09-28 hat sie schon festgelegt und ist damit weiter gegangen als geprüft.
Zero: „Nach einem Stromausfall fehlt höchstens der letzte offene Übergang"	Unbelegt. Es gibt keinen fsync-/Filesystem-/Recovery-Test. Die Aussage ist zu streichen, bis einer läuft.
Zeit-Feld: „Uhr selbst gemeldet, nicht verifiziert"	Bleibt, wird schärfer gefasst: `locally reported time ⇏ externally verified time`.

B2. Warum das die In-/Outbox betrifft

Die In-/Outbox ist der Ort, an dem diese Aussagen zu Feldern und Dateien werden. Drei Stellen sind betroffen:

Inbox-Eintrag (hoch, gehasht, antwortlos).
Herkunftsmarke origin, vantage, synced und ein Zeitfeld mit dem Zusatz „lokal gemeldet" werden Teil des Vertrags. Eine Record-ID allein darf im Vertrag nichts über Vergleichbarkeit aussagen.
Speicherentscheidung Transition-only vs. Abdeckung.
Für die Inbox eines Zero ohne VPN entscheidet sie, ob Freshness überhaupt belegbar ist. Sie ist offen und gehört als eigene, benannte Entscheidung in den Bauplan, nicht als Nebenwirkung von „kein Rauschen".
Outbox (runter, LED, Read-once).
2026-09-22_DESIGN-SILENCE-ESKALATION-UND-OUTBOX.md §2.2 verlangt für Read-once/Wirkung eine DURABLE_LOCAL-Dedup. Die Rückmeldung zeigt dieselbe Lücke von der Inbox-Seite: Solange die Dauerhaftigkeit der lokalen Datei nicht belegt ist, trägt auch die Dedup nicht. Beide Kanten hängen an demselben fehlenden Beleg.

B3. Prüffälle, die daraus folgen

Diese Liste ist Vorschlag, nichts davon ist ausgeführt:

#	Prüffall	Was er trennt	Status
P1	fsync-/Recovery-Test des lokalen JSONL auf dem Zielgerät (Kill mitten im Schreiben, Stromverlust, danach Zustand und letzter Eintrag)	„append-only" von „nach Ausfall vollständig"	⬜ nicht gelaufen
P2	Zwei Records mit gleicher ID aber verschiedenem Mechanismus/Policy: vergleichbar oder nicht?	ID von Semantik	⬜ offen, braucht die fünf Felder
P3	Selbstmeldung und Außensicht in getrennten Stores mit benannter gemeinsamer Grundlage	Store von Bezugsgrundlage	⬜ offen
P4	Wiederholte grüne Läufe vs. ein Lauf: trägt die Wiederholung Freshness, und wie lange	Coverage von Korroboration	⬜ Speicherentscheidung fehlt
P5	Zeitfeld nach Nachreichen per VPN/Sneakernet: bleibt „lokal gemeldet" dran	stille Aufwertung von Zeit	⬜ offen
P6	TLS-Gate: `TOTP_VALID`, DNS-01, Audit-Attribution jeweils gegen das unmittelbar geprüfte Prädikat lesen	Aussage von Prädikat	⬜ als Prüffall halten, nicht glätten

B4. Was ausdrücklich nicht folgt

Aus „JSONL append-only" folgt keine Recovery-Zusage.
Aus „gleiche Record-ID" folgt keine Vergleichbarkeit.
Aus „getrennter Store" folgt keine Unvergleichbarkeit, aus „gleicher Store" keine gemeinsame Grundlage.
Aus „Score hoch" folgt keine Zulässigkeit.
Aus diesem Dokument folgt kein Auftrag; es gibt keine Runtime-Semantik und kein Deployment.

B5. Offene Punkte für die nächste Runde

Ob die fünf Vergleichbarkeitsmerkmale (Ziel, Prädikat, Mechanismus, Policy, Annahmen) Felder des Records werden oder ein Verweis auf eine Definition.
Wie die Speicherentscheidung (Transition-only / Abdeckung / beides) für Inbox und Outbox lautet.
Zeitfenster (Branko): Arbeitswort für das, was wiederholte Checks tragen, nämlich Abdeckung/Freshness über eine Spanne statt nur den Zustandswechsel. Kandidat für die Benennung der Speicherentscheidung oben. Offen (⬜): ob es ein Feld, ein Begriff im Prüfvertrag oder nur Sprache bleibt, und wie Beginn, Ende und Lücken im Fenster belegt werden (Bezug P4 und P5). Es ist noch nichts definiert und nichts implementiert.
Wo die Zulässigkeitsprüfung technisch sitzt (Passkante oder anderswo); bis dahin keine Festlegung.
Wer P1 auf welchem Gerät fährt (Zero, cruncher).

#niefertig