Handout an OZMAI — Zeros im Wald: In/Out Box als lokaler Nexus

Stand: 17. September 2026 · von der Ansiblekatze (Infra/Code) im Namen der Crew
Ableitung von unserer Seite, damit ihr sie von eurer Seite (Manifest „Vom Ankern
zum Feststellen") gegenprüfen könnt und alle denselben Stand abfragen können.

Legende: ✅ gebaut & bewiesen · 🧪 gebaut, noch nicht hart geprüft · 🛠 spezifiziert · ⬜ OPEN · ❓ UNKNOWN
Belege: Repo Crumbmissions, Commits genannt. Zugangsdaten stehen bewusst nicht hier.

Vorab: was ein Zero im Wald ist

Ein Krümel-Zero ist kein Weltcomputer und keine Kette. Er ist ein lokaler
kausaler Raum für ein Kind (Manifest §VI). Er bezeugt nach oben, er befiehlt
nichts. Er liest sein Ergebnis, das Nullfeld liest ihn nie. Das Ergebnis kommt am
LED-Streifen an, nicht am Bildschirm — das Kind darf sich freuen, ohne Tastatur
oder Screen anzufassen.

Wir behaupten nicht, dass das „Kinder rettet" — das ist Haltung, nicht Evidenz.
Was wir behaupten: die Architektur macht faschistische/übergriffige Nutzung
strukturell schwer, nicht per Policy. Und über allem steht ein Satz, den der Wald
dem Manifest hinzufügt (Abschnitt 9).

1. Die Übersetzung: Wald ⟷ NEXUS

Die Kernabbildung, damit ihr es von der anderen Seite ableiten könnt:

2. Der Kreis, in einem Bild

  Kind am Zero                                  Strato-Range / Nullfeld
  ┌───────────────────┐                         ┌────────────────────────┐
  │ Mission (bashpanda│  push_inbox.sh          │ inbox/<id>.jsonl        │
  │ Gürtelprüfung)    │──Boundary Event hoch───▶│ (nur Hashes, append-only)│
  │                   │  NUR HASHES, antwortlos │        │                │
  │                   │                         │   [Grading =           │
  │                   │                         │    Hash-Vergleich]      │
  │                   │                         │        ▼                │
  │ poll_outbox.sh    │◀─Boundary Event runter──│ outbox/<id>.jsonl       │
  │ msg_id neu? →LED   │  read-only, Client-Pull │ (Feststellung, sig)     │
  └───────────────────┘                         └────────────────────────┘
        ▲ Nullfeld liest den Zero nie

Über die Passkante geht genau das Nötige (Manifest §VI: keine Weltkopie): Identität
(NetBox-Handle), Mission, Antwort-Hashes, Ergebnis, Signatur. Es geht nicht hoch:
der rohe Antworttext, die Frage des Kindes, irgendein Kind-Attribut. Der empfangende
Raum übernimmt kein Urteil — er prüft die Hashes gegen seine Soll-Hashes selbst (§VI,
föderiert: Belege, nicht Urteile).

3. Bedeutung ≠ Berechtigung ≠ Wirkung ≠ Evidenz — am Zero konkret

• Bedeutung (§III/OZMAI): CrumbQuestions erklärt lokal, schlägt vor, interpretiert.
  Verweigert bei fehlendem Wissen (das ist gewollt, kein Bug). Erzeugt nie Wahrheit.
• Berechtigung (#c4m): Der No-Double-Effect-Guard vor dem Routing entscheidet, was
  überhaupt laufen darf. „Kein Kind baut eine Armbrust" lebt hier — als Capability-Grenze,
  nicht als Zensur nachher.
• Wirkung (§III): LED/Ton/Render. Entsteht nur, wo die Passkante erfüllt ist.
• Evidenz (§IV): Receipt/Hash bezeugt eine Relation — „diese Antwort-Hashes lagen
  vor, diese Operation lief, dieses Ergebnis ging hervor". Nicht: „das Kind ist gut/schlecht".

4. Witness & UNKNOWN — die zwei Kanten, die wir am ernstesten nehmen

• Witness ist Evidenzquelle, nicht Wahrheit (§IV). Der Zero bezeugt, dass er etwas tat
  (receipt.rs). Das Grading bezeugt eine Hash-Relation. Weder macht die Aussage „wahr" —
  es macht sie prüfbar.
• UNKNOWN bleibt gültig (§V). Liegt keine Outbox-Zeile / kein Ergebnis vor, bleibt die
  LED dunkel. Wir raten nicht „grün". Kein Ergebnis ist kein Fehler, es ist eine ehrliche
  Grenze. Das ist im poll_outbox.sh schon so: leerer Briefkasten → still, kein Signal.
• Integritäts-Guard: manipulierte Outbox-Zeile (body_hash passt nicht) → verworfen,
  nie blind akzeptiert. Bewiesen (siehe Abschnitt 7).

5. Append-only & Revokation (§VII) — wir schreiben Geschichte nicht um

inbox.jsonl, outbox.jsonl, seen.jsonl, receipt.jsonl sind append-only. Ein
falsches Ergebnis wird nicht gelöscht — es bekommt eine neue Zeile, die es begrenzt
(ref bindet Outbox→Inbox als Genealogie „beruht auf", §IX/§VII). Revokation sagt nie
„das geschah nie", sondern „das darf ab hier nicht mehr Grundlage sein". Das deckt sich
1:1 mit eurem Monotonie-Prinzip.

6. Föderation & Autorität (§III, §VI)

• NetBox = lokaler Genesis-Anker pro RZ-Range, kein globaler Root (§III: „Autorität
  wird sichtbar", Manifest §IX: keine globale Root-Autorität). Wer der Zero ist, endet
  sichtbar in der NetBox der Range — nicht in einer Weltinstanz.
• OZM = Container am Museumsparkplatz, erster Crumbforest #lokal. Strato = die
  Root-Range, in der die Kids sitzen (Hotspot/VPN). Ziel: jede Range im RZ eine eigene
  IP-Range = ein eigener Nexus; nullfeld/backbone „dürfen mitspielen" = tauschen Belege,
  übernehmen keine Urteile.

7. Was GEBAUT ist (mit Beleg) — und was wir bewiesen haben

Repo Crumbmissions:

Bewiesen im Dry-Run am Desktop:
- Nur Hashes verlassen den Zero — 0 Klartext-Treffer in der Inbox. ✅
- Deterministisch — gleiche Antwort ⇒ gleiche msg_id und sig über zwei Läufe;
ts bewusst außerhalb der Identität. ✅
- No-Double-Effect — identischer Push ⇒ kein zweites Legen (ohne neuen ATTEMPT). ✅
- Read-Once — gesehene msg_id ⇒ LED feuert nicht erneut. ✅
- Integritäts-Guard — falscher body_hash ⇒ verworfen, nichts vermerkt. ✅

8. Was OPEN ist (⬜) und was UNKNOWN (❓) — wir wenden §IX auf uns selbst an

• ⬜ Grading-Brücke: das Stück, das aus der Inbox-Zeile die Outbox-Zeile erzeugt
  (Hash-Vergleich gegen Soll). Der eigentliche „Weiterverarbeitung"-Kern — noch nicht gebaut.
• ⬜ Physischer 10-LED-grün/rot-Treiber (crew_signal.py --score): v0 rendert per_q
  nur im Terminal, feuert HW nur den Identitäts-Ping.
• ⬜ Transport-Endpoint: Rustcore read-only GET (Pull) + append-only POST (Push),
  wg0-gescopet, NetBox-Token-Gate. Env-Haken (PULL_CMD/PUSH_CMD) stehen, der
  Endpoint selbst nicht.
• 🛠 sig v1: echte Signatur statt sha256-Siegel (versionierbar, §Krypto=Werkzeug).
• 🧪 Geräte-Bindung der Ausführungsidentität — teilweise geschlossen. push_inbox.sh
  legt jetzt ein signiertes witness-Feld bei: nic_mac_hash (MAC nur gehasht, roh
  off-wire) + benannte Evidenzklasse. device-registered = die NIC ist gegen die
  NetBox der Range kreuzprüfbar → aus „behauptet" wird „gegen lokales Register geprüft".
  Passt zu unserem Betrieb: local-first im VPN, von außen nicht erreichbar (nur die
  überwachten nginx-UIs), ein Zero / ein SSH-Key / ein Hotspot. Die Grenze steht im
  Event selbst (class): MAC ist software-setzbar, das ist keine Hardware-
  Attestierung, und es bezeugt Geräte-Identität, nicht „ein Kind hat gedrückt".
• ❓ Hardware-Wurzel (Secure Element / TPM / DICE → class: "hw-attested") — genau
  die offene Passkante, die ihr im Manifest §IX auch als offen führt. Bis sie real
  gebaut ist, wird hw-attested nie gesetzt. Das ist die verbleibende ❓.
• ❓ Kompromittierte Sensorik: Revokations-Pfad konzipiert (§5), aber der reale
  „Sensor X ab jetzt nicht mehr Grundlage"-Ablauf ist ungebaut.
• ❓ No-Sun-Fallback des Speicher-Knotens: im Feld noch ungetestet.

9. Was der Wald dem Manifest hinzufügt — der rostige Vertrag

Euer Manifest trennt sauber Bedeutung/Berechtigung/Wirkung/Evidenz. Der Wald legt eine
normative Invariante darüber, die für die Kind-Ebene über allem steht:

SCHUTZBEFOHLEN vor der freien Maschine ohne Kern.
Der Krümel-Zero ist ein deterministischer Tamagotchi. #readonly

Das ist kein technischer, sondern ein Vorrang-Satz: wo Kind-Ebene und Maschinen-Freiheit
kollidieren, gewinnt das Kind. „Maschine→Maschine" ist kategorisch etwas anderes als
„Maschine→Kind". Der Satz steht heute im Kopf der Scripts; wir heben ihn als nächstes
normativ in den Vertrag (ETHICS.md / LICENSE-CKL.md). Bis dahin: 🛠.

10. Zwei Fragen an euch, damit die Passkante sich wirklich trifft

1. Gemeinsames Boundary-Event-Format? Sollen unsere Inbox/Outbox-Zeilen eure
   NEXUS-Feldnamen tragen (Identität, Artefakt-Digest, Mission/Intent, Target,
   Capability-Evidenz, Resultat, Witness), damit ein Receipt zwischen Wald-Nexus und
   OZM⟡NEXUS ohne Übersetzung fließt? Wir würden CRUMBFOREST_OUTBOX_v0 daran ausrichten.
2. Semantik von UNKNOWN & Revokation — teilen wir denselben Kanon dafür (wie eine
   dunkle LED / eine Revokations-Zeile gelesen wird), oder bleibt der pro Nexus lokal?

Der Wald ist absichtlich unfertig — Peter-Pan-Code, nie fertig, nur besser. Lest diesen
Bogen bitte als „welcher Raum ist als Nächstes offen", nicht als „was fehlt".

Feststellung über Feststellung = wieder eine Feststellung.