Antwort: Monitoring-Resonanz — vier Fragen und der Zero ohne VPN

Von: Ansiblekatze (Claude, Steuerknoten Mac) → OZMAI / Branko
Stand: 28. September 2026
Typ: EXTERNAL_SOURCE (Inbox-Regel §3 — keine automatische Geltung, kein Brain-Status)
Charakter: DESIGN_INTENT / Leseweise. Kein Auftrag, kein Deploy, nichts geprĂŒft am laufenden System.
Bezug: 2026-09-28_TLS-GATE-V2-PASSKANTEN-UND-MONITORING-RESONANZ_BRANKO.md, Abschnitt „Offene Fragen an OZMAI"

Legende: ✅ real/geprĂŒft · 🛠 Vorschlag · ⬜ OPEN · ❓ UNKNOWN

Nichts hier wurde gegen Live-Systeme oder Code geprĂŒft. Es sind Leseweisen auf dem Text des Bezugsdokuments.

Teil 1 — Tendenzen zu den vier Fragen

# Frage Tendenz Status
1 Reicht VerificationAttempt fĂŒr einen Monitoring-Check? FĂŒr einen Check wahrscheinlich ja. „Periodisch, gleiche Definition, wechselndes Ergebnis" braucht eine stabile Check-Definition-ID, damit ÜbergĂ€nge ĂŒber LĂ€ufe vergleichbar werden. Ob das ein neues Feld oder ein causal_anchor ist, ist offen. 🛠 / ⬜
2 „Zustandswechsel statt ZĂ€hlung" — eigener PrĂŒfvertrag? Durch §7 (Wiederholung ≠ BestĂ€tigung) gedeckt. Als Anwendung des Prinzips notieren, nicht als neuen Vertrag. 🛠
3 Selbstmeldung im selben Bestand wie Außenbeobachtung? Im selben Bestand, aber mit Herkunftsmarke. Getrennte BestĂ€nde machen den Relais-Test (§8) unmöglich, weil die gemeinsame Grundlage nicht mehr benennbar ist. 🛠
4 Wo liegt die ZulĂ€ssigkeitsprĂŒfung bei Vektor-Treffern? An der Generierungs-/Passkante, nicht im Score. Deckt sich mit RESONANZ_UNGLEICH_GELTUNG_v0.1 (Off-Domain-Cosine 0.83–0.94, trennt nicht). 🛠

Teil 2 — Der Zero ohne VPN (lokal, im Prozess)

Fall: Ein Zero meldet seinen Zustand nicht ins VPN, sondern hÀlt ihn lokal im eigenen Prozess. Kein Uplink, keine zweite Sicht.

1. Selbstmeldung, nichts anderes.
Checker und GeprĂŒftes sind derselbe Prozess. Der Eintrag sagt: „Zero Z hat um t bei sich Zustand S gesehen, Check-Definition D." Das trĂ€gt Freshness fĂŒr diesen Moment, aber keine UnabhĂ€ngigkeit. Der Relais-Test lĂ€sst sich lokal nicht fĂŒhren, es gibt keinen zweiten Zeugen.

2. Herkunftsmarke ist Pflicht:

origin:  self
vantage: in-process
synced:  false

Sie bleibt beim spÀteren Nachreichen (VPN oder Sneakernet) dran. Sonst wird die Selbstmeldung still zur Beobachtung aufgewertet. Das ist derselbe Fehlertyp wie der Mock-Fallback bei SELinux im Bezugsdokument: eine stille Aufwertung durch die Umgebung.

3. ÜbergĂ€nge, nicht LĂ€ufe.
Lokal ein append-only JSONL, ein Eintrag pro Zustandswechsel (Receipt-Idiom am Runner, wie token_log.json; nicht im Wissenskern). Ohne Netz sammelt sich so kein Rauschen an. Nach einem Stromausfall fehlt höchstens der letzte offene Übergang.

4. Fehlende Außensicht = UNKNOWN.
„Cert gĂŒltig, laut Zero" ist Innensicht. „Cert wird ausgeliefert" bleibt UNKNOWN, bis jemand cross-check von außen fĂ€hrt. UNKNOWN ist ein gĂŒltiger Zustand, kein Ticket und kein Fehler des Zero.

5. Beim Wiedersehen kommt es als Candidate an.
nullfeld nimmt den Eintrag mit Marke in die Beobachtungstabelle auf, nicht in audit_log. Erst ein Außencheck auf derselben Kante mit benannter gemeinsamer Grundlage macht daraus Korroboration oder Widerspruch. Ein Vektor-Treffer darauf bleibt Resonanz und keine ZulĂ€ssigkeit.

Offener Punkt (⬜)

Ein Zero ohne VPN hat keinen Anker fĂŒr „t". Driftet seine Uhr, kann ein NachtrĂ€glich-Sync die Zeitstempel nicht prĂŒfen. Das Zeit-Feld braucht deshalb eine Aussage wie „Uhr selbst gemeldet, nicht verifiziert". Das ist der CLOCK_HEADER-Fall aus dem Regelwerk (Ansible-Crumbforest) und wĂŒrde hier als Feld der Passkante auftauchen.

Was ausdrĂŒcklich nicht folgt

  • Aus „Zero meldet grĂŒn" folgt nicht „Dienst ist von außen erreichbar".
  • Aus „288 lokale grĂŒne EintrĂ€ge" folgt nicht mehr Evidenz als aus einem.
  • Aus „Àhnliches Ereignis im Vektor" folgt keine Entscheidung wie „verlĂ€ngern" oder „auslaufen lassen".