Jeder Vorgang kennt seinen Zustand

Am 4. September 2026 um 13:27 Uhr rief ein Kunde den Auswertungsbericht zu seinem Genom ab. Zwei Sekunden nach dem Versand hatte sein Mailserver die Zustellung bestätigt, eine Minute später war er angemeldet, dann hatte er das Angebot angesehen, dann vier Dateien geholt. Jede dieser Handlungen stand in unserer Datenbank, bevor jemand danach gefragt hat.

Neun Tage davor sah derselbe Vorgang von außen genauso aus: versendet. Der Empfänger war im Ausland, der Zugangslink lief nach 72 Stunden ab, und als er ihn öffnete, war er tot. Niemand wusste das – er nicht, dass er in eine leere Adresse klickte, wir nicht, dass er draußen stand. Wir haben es erfahren, weil er es uns geschrieben hat. Diese neun Tage sind der Grund für das, was hier beschrieben wird.

Der vordere Teil der Kette ist beschrieben: von der Frage zum Angebot, vom Angebot zur Bestätigung, von der Probe zum Lauf, vom Lauf zur freigegebenen Lieferung. An ihrem Ende steht eine Nachricht an den Kunden – und damit endete bisher, was das System wusste. Ab dem Absenden begann die Vermutung, und die Vermutung endete erst, wenn der Kunde sich meldete.

Wer ein Labor betreibt, kennt die Folge. „Haben Sie die Daten erhalten und gesichert?“ wird per Mail gefragt, per Mail beantwortet, und die Antwort wandert in eine Akte. Nicht, weil jemand das so will, sondern weil das System, das die Daten geliefert hat, nicht sehen kann, ob sie angekommen sind. Der Zustand eines Vorgangs wurde von Hand geführt, in Posteingängen, mit Erinnerung als Datenbank.

Diese Lücke ist geschlossen. Der Kontaktverlauf verlängert die Kette vom Versand bis zur Handlung – und macht den Zustand jedes Vorgangs zu einer Tatsache im System statt zu einer Frage an einen Menschen.

Bisher war das erste Glied das einzige: versendet. Jetzt folgen fünf weitere, jedes mit Zeitpunkt und Person.

• Zugestellt – der Server des Empfängers hat die Nachricht angenommen. Ein Nachweis, kein Indiz.
• Zugangslink – ausgestellt, gültig bis, benutzt am. Ein Link, der abläuft, bevor jemand ihn öffnet, steht als eigener Eintrag in der Leiste. Genau das ist die Zeile, die im Fall oben gefehlt hat.
• Angemeldet – die Person ist im Portal.
• Angesehen – Angebot, Bericht, Dokument.
• Abgerufen – welche Datei, wann, von wem.
• Gehandelt – Angebot angenommen, Zeichnung geleistet, Aufgabe erledigt.

Dazwischen liegen Öffnungen und Klicks. Wir zeigen sie an, aber wir beschriften sie als das, was sie sind: Hinweise. In einem einzigen Monat zählte das Versandwerkzeug bei uns mehr Öffnungen als Nachrichten – Mailfilter in Kliniken und Instituten öffnen Nachrichten und rufen Links auf, lange bevor ein Mensch sie sieht. Eine Öffnung beweist nichts. Die Anmeldung beweist alles. Ein System, das beides gleich behandelt, erzählt eine Geschichte, die nicht stimmt; deshalb trennt der Verlauf belegt von Hinweis, sichtbar in jeder Zeile.

Nachrichten zu verfolgen ist keine neue Idee. Jedes Versandwerkzeug meldet seit fünfzehn Jahren Öffnungen und Klicks, und wer damit zufrieden ist, braucht nichts Neues. Der Unterschied liegt nicht darin, ob verfolgt wird, sondern woran.

Ein Mailwerkzeug misst die Nachricht. Es kennt weder den Auftrag, zu dem sie gehört, noch das Angebot, das sie ankündigt, noch die Datei, die dahinter liegt. Es sieht das erste Glied der Kette und nennt eine Öffnung eine Lektüre. Die fünf anderen Glieder finden dort statt, wo ein Mailwerkzeug nie hinkommt: im Portal. Und das Portal gehört dem Labor, das Atlas OS unter eigener Domain betreibt.

Atlas OS misst den Vorgang. Die Nachricht ist ein Eintrag von sechs, und die Einheit der Wahrheit ist nicht „wurde die Mail geöffnet“, sondern „in welchem Zustand ist dieser Auftrag, und was ist der nächste Schritt“. Das ist der Unterschied zwischen einem Werkzeug, das Statistik liefert, und einer Schicht, die den Betrieb kennt.

Zwei Dinge folgen daraus, die für ein Labor mehr wert sind als jede Öffnungsrate. Stille wird lesbar: „hat es gelesen und denkt nach“ und „hat es nie bekommen“ sahen bisher identisch aus – jetzt sind es zwei Zustände mit zwei Antworten, nachfassen oder in Ruhe lassen. Und der Verlauf ist ein Nachweis: bei genetischen Daten ist die Frage, wer wann welchen Befund abgerufen hat, keine Komfortfunktion, sondern das, was eine Prüfung nach ISO 15189 oder eine Datenschutzanfrage verlangt. Wer Atlas OS betreibt, hat die Antwort, ohne sie je geführt zu haben.

Atlas OS ist für Agenten gebaut und für Menschen lesbar. Das ist keine Formulierung, sondern eine Reihenfolge: dieselben Ereignisse, die ein Mensch am Auftrag als Zeitleiste sieht, sind der Zustand, aus dem der Agent den nächsten Schritt ableitet.

Jeder Zustand hat einen nächsten logischen Schritt. Ergebnisse bereit, seit vierzehn Tagen nicht abgerufen: erinnern. Einladung zugestellt, Link abgelaufen, keine Anmeldung: neuen Link ausstellen. Angebot angesehen, nicht gezeichnet, Frist in drei Tagen: nachfassen. Bericht abgerufen: nichts tun, der Vorgang läuft. Der Agent liest den Verlauf, erkennt den Zustand und bereitet den Schritt vor – die Nachricht als Entwurf, den Link als Vorschlag, die Erinnerung als Aufgabe.

Dann kommt der Mensch. Er schreibt nicht, er sucht nicht, er fragt nicht nach. Er triagiert: ist der Schritt richtig erkannt, ist er richtig vorbereitet, geht er raus. Jede schreibende Handlung zeigt vor der Ausführung ihre Vorschau und wartet auf ein Ja. Was verschwunden ist, sind die Handgriffe und das Raten. Was geblieben ist, ist die Entscheidung – und die soll bleiben.

Das ist der Grund, warum der Kontaktverlauf nicht als Bericht gebaut ist, sondern als Ereignisstrom. Ein Bericht wird gelesen. Ein Strom wird verarbeitet.

Jeder Abruf einer Ergebnisdatei hinterlässt eine Zeile: Zeitpunkt, Person, Datei, Weg. Für die großen Datenpakete, die das Portal nicht transportiert, sondern autorisiert, gilt dasselbe – die Adresse entsteht beim Klick, gilt begrenzt, und der Klick steht im Verlauf.

Die Rückmeldungen des Versandwegs werden einzeln gespeichert, nie überschrieben: zugestellt, verzögert, abgewiesen, geöffnet, geklickt, mit Zeitstempel und Rohereignis. Die technischen Spuren einer Öffnung – Adresse und Programm des Empfängers – sind personenbezogen und werden nach zwölf Monaten gelöscht; die Ereigniszeile bleibt, denn sie gehört zum Vorgang, nicht zur Person. Ein Zugangstoken läuft nie über einen fremden Umleiter: Nachrichten, die einen Schlüssel tragen, sind von der Linkverfolgung ausgenommen, automatisch, weil die Regel am Inhalt hängt und nicht an einer Liste.

Das ist Buchführung, und es soll wie Buchführung wirken. Wer in zwei Jahren wissen will, wann ein Befund an wen ging und wann er abgerufen wurde, bekommt keine Erinnerung als Antwort, sondern eine Zeile.

Der Anlass war ein Vorgang bei uns selbst. Eine Ergebnislieferung, dreimal eingeladen, jede Einladung angenommen – und trotzdem kam der Empfänger neun Tage lang nicht an seine Daten, weil ein Link ablief, während er unterwegs war. Der Verlauf hätte am dritten Tag gesagt: zugestellt, Link abgelaufen, nicht benutzt, keine Anmeldung. Die Antwort darauf ist ein neuer Link, keine Nachfrage.

Seit der Verlauf steht, sind über denselben Auftrag Zustellung, Anmeldung und Abruf durchgelaufen – die Kette vom Anfang dieses Textes. Die Zustellbestätigung kam zwei Sekunden nach dem Versand. Zwischen Anmeldung und dem ersten Abruf lagen siebzig Minuten, in denen der Kunde gelesen hat. Das wissen wir, weil es dasteht.

Was hier nicht steht, steht aus Absicht nicht hier. Kein Kunde wird genannt, kein Befund erscheint, und Ergebnisse aus laufenden gemeinsamen Vorhaben zeigen wir erst, wenn die Beteiligten sie freigeben. Wessen Daten wir verarbeiten, entscheidet, wann darüber gesprochen wird.

Atlas OS führt heute drei Hauptbücher je Auftrag. Der Lauf: welches Werkzeug, welche Version, welche Prüfsumme, von wann bis wann. Die Lieferung: welche Datei, von wem freigegeben, an wen. Und seit dieser Woche der Kontakt: was den Kunden erreicht hat und was er getan hat. Zusammen beschreiben sie einen Auftrag vom Eingang der Rohdaten bis zur Hand des Empfängers ohne eine Lücke, in der jemand raten müsste.

Das ist die Grundlage, auf der Agenten arbeiten können. Ein Agent braucht keine Oberfläche und keine Zusammenfassung; er braucht den Zustand, und zwar vollständig. Drei Bücher, die ineinandergreifen, sind dieser Zustand. Was in den kommenden Wochen dazukommt, folgt aus derselben Struktur: jede ausgehende Nachricht setzt eine Erwartung mit Frist, und was die Frist reißt, meldet sich von selbst – auf der Startseite des Betreibers und in der Liste des Agenten. Antworten der Kunden hängen sich an den Auftrag, statt in einem Posteingang zu liegen. Der Verlauf wird damit beidseitig.

Jedes Labor, das Atlas OS unter eigener Domain betreibt, hat diesen Verlauf für die eigenen Kunden – in der Schicht, die es selbst besitzt, nicht in einem Werkzeug daneben.

Der Anspruch ist derselbe wie beim Lauf, und deshalb steht er hier noch einmal: kein Vorgang soll länger als einen Tag in einem Zustand stehen, den niemand kennt. Der Agent sieht ihn zuerst. Der Mensch entscheidet.

Auftrag, Lauf, Lieferung und Kontaktverlauf liegen im Portal unter app.atlasbiolabs.com. Wie der Weg von den Rohdaten zum freigegebenen Ergebnis läuft, steht hier.