# Koch Laboratory — Ewidencja, która ma przekonać kogoś, kto nie ufa jej autorowi (Laborbuch) · Forschungsportfolio / Portfolio badawcze / Research Portfolio

> **Zasada publikacji.** Konstrukcje dowodowe (kanoniczny zapis, łańcuch stempli, tryb hash-only) są opisane co do zasady działania — dowód, którego nie da się odtworzyć bez pytania autora, nie jest dowodem. Wstrzymane pozostają szczegóły wdrożeń u klientów.
> **Zasada uczciwości.** To wpis o problemie projektowym, nie o produkcie: claimy produktowe żyją na stronie marki, w czasie teraźniejszym. Tam, gdzie własność jest ograniczona — a jest w kilku miejscach — granica jest podana wprost, łącznie z tą najbardziej niewygodną: jeden z dwóch kanałów czasu jest naszą własną usługą.

---
---

# 🇵🇱 WERSJA POLSKA

## Koch Laboratory — ewidencja, która ma przekonać kogoś, kto nie ufa jej autorowi

Ewidencja czasu pracy badawczej jest szczególnym rodzajem dokumentu: sporządza ją ten, kto na niej korzysta, a czyta ktoś, kto zawodowo zakłada, że mogła powstać wczoraj. Cała trudność techniczna bierze się z tej asymetrii — nie z liczenia godzin. Ten kierunek pyta, jakie własności musi mieć zapis, żeby jego wiarygodność nie zależała od dobrej woli autora, i gdzie leżą granice tego, co da się w ogóle wykazać.

**Metodyka.** Problem → hipoteza → falsyfikowalne kryterium → wynik z warunkami brzegowymi. Statusy jawne; zmiany projektowe wymuszone zderzeniem z rzeczywistością są opisane jako zmiany, nie wygładzone po fakcie.

### 1. Kierunek 1 — zapis, w którym nie ma czego poprawić
**Pytanie badawcze.** Czy da się prowadzić ewidencję tak, żeby brak możliwości poprawienia wpisu był własnością systemu, a nie deklaracją jego użytkownika?
**Dlaczego to trudne.** Każdy system dopuszczający edycję jest, z punktu widzenia czytającego, tym samym co arkusz kalkulacyjny — a ludzie popełniają błędy i muszą je korygować. Zakaz edycji bez mechanizmu korekty jest więc nie do utrzymania w praktyce; mechanizm korekty bez śladu niweczy cały zamysł.
**Stan techniki (publikowany).** Wymogi niezmienności zapisów w prawie podatkowym (GoBD, § 146 ordynacji podatkowej), księgowa zasada storna, nośniki i magazyny w trybie WORM, systemy zdarzeniowe.
**Kryterium sukcesu.** Po zamknięciu tygodnia nie istnieje żadna ścieżka edycji ani usunięcia wpisu; korekta jest **nowym wpisem** wskazującym wpis korygowany, a oryginał zostaje widoczny.
**Wynik.** Potwierdzony: wpisy zamknięte są niemodyfikowalne, korekta to storno ze wskazaniem, usuwanie zablokowane. Warunek brzegowy: własność dotyczy zapisu, nie nośnika — kto ma dostęp administracyjny do bazy, ma dostęp do bazy; dowodowo broni tego dopiero kierunek 4, a nie same reguły aplikacji. Mówimy to wprost, bo systemy „niezmienne z definicji" zwykle tego nie mówią.
**Status:** wdrożone.

### 2. Kierunek 2 — dwie daty zamiast jednej
**Pytanie badawcze.** Jak zapisać pracę wykonaną trzy miesiące temu, nie udając, że zapis powstał wtedy?
**Dlaczego to trudne.** Ewidencja odtwarzana po fakcie ma mniejszą wartość dowodową niż bieżąca, ale jest nieunikniona: laboratoria zaczynają dokumentować systematycznie dopiero w którymś momencie, a wcześniejsza praca istniała naprawdę. System, który pozwala wpisać datę pracy bez śladu, kiedy powstał wpis, zamienia całą ewidencję w zapis o jednej, nieweryfikowalnej jakości.
**Stan techniki (publikowany).** Rozróżnienie czasu zdarzenia i czasu zapisu w bazach dwuczasowych; wymóg „zeitnah" w metodyce ulgi badawczej.
**Kryterium sukcesu.** Data pracy i data sporządzenia są osobnymi polami, druga nadawana automatycznie; reżim wpisu (bieżący / rekonstrukcja) jest jawny i przeżywa import starych materiałów.
**Wynik.** Potwierdzony: dwa pola dat i dwa reżimy, import dawnej księgi wchodzi jako rekonstrukcja i pozostaje tak oznaczony na zawsze. Efekt uboczny okazał się ważniejszy od zamierzonego: **jawne przyznanie się do rekonstrukcji podnosi wiarygodność pozostałej części ewidencji**, zamiast ją obniżać.
**Status:** wdrożone.

### 3. Kierunek 3 — kotwice uprawdopodabniają, ale nie mierzą
**Pytanie badawcze.** Jaka jest właściwa rola śladów maszynowych (commity, pliki, metadane) w ewidencji, której przedmiotem jest praca umysłowa?
**Dlaczego to trudne.** Pokusa jest oczywista: skoro commit ma sygnaturę czasu, niech commit wyznacza godziny. Prowadzi to jednak do dwóch fałszów naraz. Po pierwsze, praca badawcza w znacznej części odbywa się poza komputerem — analiza, projektowanie, czytanie — i zapis oparty na kotwicach po prostu jej nie widzi. Po drugie, system wymagający kotwicy uczy ludzi **produkowania kotwic**, czyli psuje dokładnie ten materiał, który miał uwiarygadniać.
**Stan techniki (publikowany).** Narzędzia mierzące czas z aktywności aplikacji; ewidencje oparte na integracjach z repozytoriami.
**Kryterium sukcesu.** Kotwice są dowodem uprawdopodabniającym, nigdy warunkiem wpisu; godziny pozostają oświadczeniem wnioskodawcy; praca poza komputerem ma własne, jawne oznaczenie zamiast być luką.
**Wynik.** Potwierdzony jako rozstrzygnięcie projektowe: kotwice (commity, pliki dowodowe) podpinają się automatycznie tam, gdzie istnieją, a wpis bez kotwicy jest pełnoprawny i oznaczony jako praca koncepcyjna. Hipoteza „kotwica jako warunek wpisu" została odrzucona — kosztem wygodnej narracji, na rzecz zapisu, który nie kłamie o naturze pracy badawczej.
**Status:** wdrożone (hipoteza konkurencyjna odrzucona).

### 4. Kierunek 4 — dowód, który przeżywa system, w którym powstał
**Pytanie badawcze.** Czy niezmienność zapisu da się wykazać komuś, kto nie ma dostępu do systemu — i wykazać nadal wtedy, gdy systemu już nie ma?
**Dlaczego to trudne.** Dowód wewnętrzny jest wart tyle, ile zaufanie do operatora; a operator jest tu jednocześnie beneficjentem. Dowód zewnętrzny wymaga natomiast, żeby to, co wychodzi na zewnątrz, nie zawierało treści — bo treść ewidencji badawczej jest tajemnicą przedsiębiorstwa.
**Stan techniki (publikowany).** Znaczniki czasu RFC 3161, OpenTimestamps z zakotwiczeniem w Bitcoinie, drzewa Merkle i logi transparentności, podpisy Ed25519.
**Kryterium sukcesu.** Tydzień zamykany jako kanoniczny zapis → SHA-256 → stempel w **co najmniej dwóch** kanałach; weryfikacja możliwa bez dostępu do instancji i po jej całkowitej utracie.
**Wynik.** Potwierdzony w zakresie kryterium: kanoniczna postać wpisów tygodnia, skrót, stempel w podpisanym logu z drzewem Merkle oraz drugi, niezależny stempel OpenTimestamps zakotwiczony w Bitcoinie; dowody leżą jako pliki obok systemu. **Zastrzeżenie i jego rozwiązanie.** Pierwszy kanał to nasza własna usługa czasu — sam podpis operatora niczego by więc nie przesądzał. Rozwiązaniem nie jest zapewnienie, tylko konstrukcja: log tej usługi nie poświadcza sam siebie, ponieważ korzeń każdego zamkniętego tygodnia jest kotwiczony na zewnątrz — w Bitcoinie przez OpenTimestamps oraz w tytule przelewu księgowanym przez bank, z publikowaną referencją księgowania. Zostaje jedna granica, warta wypowiedzenia: świeżo złożony stempel trafia do tygodnia jeszcze otwartego i zewnętrznie zakotwiczony zostaje dopiero po jego zamknięciu. W tym oknie wpisu broni drugi, bezpośredni stempel OpenTimestamps, składany przez samą instancję.
**Status:** wdrożone.

### 5. Kierunek 5 — dowód bez ujawnienia treści (zmiana projektowa)
**Pytanie badawcze.** Jak dołączyć do wpisu materiał dowodowy, którego właściciel nie może nikomu pokazać?
**Dlaczego to trudne.** Pierwotny projekt zakładał załączanie plików do instancji: skanów, wydruków z aparatury, danych pomiarowych. Zderzenie z rzeczywistością było natychmiastowe — dla części laboratoriów sama treść tych plików jest tajemnicą przedsiębiorstwa, a wgranie ich do jakiegokolwiek systemu, także własnego, jest decyzją, której nie chcą podejmować.
**Stan techniki (publikowany).** Zobowiązania kryptograficzne, dowody istnienia oparte wyłącznie na skrótach, obliczanie skrótu po stronie przeglądarki.
**Kryterium sukcesu.** Wariant, w którym instancja nigdy nie widzi pliku, a mimo to jego skrót wchodzi pod stempel czasu tygodnia.
**Wynik.** Potwierdzony jako **zmiana projektowa**: obok trybu z załączaniem istnieje tryb hash-only — przeglądarka liczy SHA-256 lokalnie, do systemu trafia wyłącznie odcisk. Warunek brzegowy podany wprost: taki dowód jest bezwartościowy bez oryginału. Weryfikacja polega na okazaniu pliku i porównaniu skrótu; kto zgubi oryginał, zostaje z liczbą, która niczego nie dowodzi. To cena, którą świadomie płaci się za nieujawnianie treści.
**Status:** wdrożone (oba tryby, przełączane w konfiguracji instancji).

### 6. Kierunek 6 — ewidencja, która sama się ogranicza
**Pytanie badawcze.** Czy zapis może aktywnie odcinać własne godziny — i czy takie odcięcie wzmacnia jego wiarygodność?
**Dlaczego to trudne.** Ewidencja, w której każdy tydzień kończy się równo na maksimum, jest sygnałem ostrzegawczym dla każdego czytającego, a jednocześnie naturalnym wynikiem systemu, który po prostu nie pozwala przekroczyć limitu. Praca ponad limit istnieje naprawdę; wypchnięcie jej poza zapis to strata materiału, a wpisanie w limit — nieprawda.
**Stan techniki (publikowany).** Metodyka ulgi badawczej z tygodniowym sufitem na osobę; praktyka ewidencji czasu pracy z twardymi walidacjami.
**Kryterium sukcesu.** Godziny ponad sufit są zapisywane i widoczne, ale jawnie oznaczone jako **nierozliczane**; praca rutynowa jest dokumentowana i jawnie odgraniczona od badawczej; sufit jest ustawiany per osoba, bo etaty nie są jednakowe.
**Wynik.** Potwierdzony: trzy odrębne oznaczenia (praca badawcza rozliczana, badawcza ponad sufit — nierozliczana, praca rutynowa poza zakresem), sufit tygodniowy per konto, kotwice podpinane do wszystkich trzech kategorii. Ubocznie rozwiązuje to problem ciągłości: tygodnie bez pracy badawczej przestają być dziurami w kalendarzu.
**Status:** wdrożone.

### 7. Kierunek 7 — praca zespołowa bez wglądu w godziny innych
**Pytanie badawcze.** Jak prowadzić wspólną ewidencję projektu, nie pokazując pracownikom nawzajem ich czasu pracy?
**Dlaczego to trudne.** Raport dla oceniającego musi być kompletny — z podziałem na osoby i sumami. Widok dla pracownika nie powinien ujawniać wymiaru pracy kolegów, bo to informacja o charakterze płacowym. Te dwa wymagania spotykają się w jednym zbiorze danych i w jednym eksporcie.
**Kryterium sukcesu.** Kompletność raportu zbiorczego przy jednoczesnym maskowaniu godzin między osobami — także w plikach wyjściowych, nie tylko na ekranie.
**Wynik.** Potwierdzony: raport w rozbiciu na osoby dla prowadzącego, maskowanie między pracownikami w widokach i eksportach, przypisanie autorstwa każdego wpisu. Warunek brzegowy: maskowanie chroni przed wglądem, nie przed wnioskowaniem — kto zna skład zespołu i sumę zbiorczą, część informacji odtworzy rachunkiem.
**Status:** wdrożone.

**Status kierunku.** Wszystkie siedem kierunków ma postać wdrożoną i działającą. Wynikiem, który wydaje się przenosić poza tę dziedzinę, jest obserwacja z kierunków 2, 3 i 6: **wiarygodność zapisu rośnie tam, gdzie zapis jawnie przyznaje się do własnych ograniczeń** — do rekonstrukcji, do braku kotwicy, do godzin, których nie wolno policzyć. Najbliższy krok badawczy: dziennik odczytów jako materiał dowodowy sam w sobie (kto i kiedy oglądał raport) oraz szyfrowanie kotwic w stanie spoczynku bez utraty weryfikowalności stempla.

---
---

# 🇩🇪 DEUTSCHE FASSUNG

## Koch Laboratory — eine Aufzeichnung, die jemanden überzeugen soll, der ihrem Verfasser nicht traut

Die Aufzeichnung von Forschungsarbeitszeit ist ein besonderer Dokumententyp: Sie wird von demjenigen erstellt, der von ihr profitiert, und von jemandem gelesen, der berufsmäßig davon ausgeht, sie könnte gestern entstanden sein. Die gesamte technische Schwierigkeit entspringt dieser Asymmetrie — nicht dem Zählen von Stunden. Diese Richtung fragt, welche Eigenschaften eine Aufzeichnung haben muss, damit ihre Glaubwürdigkeit nicht vom guten Willen des Verfassers abhängt, und wo die Grenzen dessen liegen, was sich überhaupt zeigen lässt.

**Methodik.** Problem → Hypothese → falsifizierbares Kriterium → Ergebnis mit Randbedingungen. Der Status ist offen ausgewiesen; Entwurfsänderungen, die die Wirklichkeit erzwungen hat, stehen als Änderungen da und werden nicht nachträglich geglättet.

### 1. Richtung 1 — eine Aufzeichnung, an der es nichts zu korrigieren gibt
**Forschungsfrage.** Lässt sich eine Aufzeichnung so führen, dass die Unmöglichkeit der nachträglichen Änderung eine Eigenschaft des Systems ist und keine Erklärung seines Benutzers?
**Warum schwierig.** Jedes System, das Änderungen zulässt, ist aus Sicht des Lesers dasselbe wie eine Tabellenkalkulation — Menschen machen aber Fehler und müssen sie berichtigen. Ein Änderungsverbot ohne Korrekturmechanismus ist in der Praxis nicht haltbar; ein Korrekturmechanismus ohne Spur zerstört den ganzen Zweck.
**Stand der Technik (veröffentlicht).** Unveränderbarkeitsanforderungen im Steuerrecht (GoBD, § 146 AO), das buchhalterische Stornoprinzip, WORM-Medien und -Speicher, ereignisbasierte Systeme.
**Erfolgskriterium.** Nach Wochenabschluss existiert kein Pfad zur Änderung oder Löschung eines Eintrags; die Korrektur ist ein **neuer Eintrag**, der auf den korrigierten verweist, und das Original bleibt sichtbar.
**Ergebnis.** Bestätigt: Abgeschlossene Einträge sind unveränderlich, die Korrektur erfolgt per Storno mit Verweis, das Löschen ist gesperrt. Randbedingung: Die Eigenschaft betrifft die Aufzeichnung, nicht den Datenträger — wer administrativen Zugriff auf die Datenbank hat, hat Zugriff auf die Datenbank; beweisrechtlich verteidigt das erst Richtung 4, nicht die Regeln der Anwendung. Wir sagen das ausdrücklich, weil Systeme, die sich „per Definition unveränderlich" nennen, es meist nicht sagen.
**Status:** umgesetzt.

### 2. Richtung 2 — zwei Daten statt eines
**Forschungsfrage.** Wie hält man Arbeit fest, die vor drei Monaten geleistet wurde, ohne vorzugeben, die Aufzeichnung sei damals entstanden?
**Warum schwierig.** Nachträglich rekonstruierte Aufzeichnungen haben geringeren Beweiswert als zeitnahe, sind aber unvermeidlich: Labore beginnen erst irgendwann systematisch zu dokumentieren, und die frühere Arbeit hat wirklich stattgefunden. Ein System, in dem sich ein Arbeitsdatum ohne Spur des Erfassungszeitpunkts eintragen lässt, verwandelt die gesamte Aufzeichnung in einen Bestand einheitlich unprüfbarer Qualität.
**Stand der Technik (veröffentlicht).** Die Trennung von Ereignis- und Erfassungszeit in bitemporalen Datenbanken; die Anforderung „zeitnah" in der Methodik der Forschungszulage.
**Erfolgskriterium.** Arbeitsdatum und Erfassungsdatum sind getrennte Felder, das zweite wird automatisch vergeben; das Erfassungsregime (zeitnah / Rekonstruktion) ist ausgewiesen und übersteht den Import alter Materialien.
**Ergebnis.** Bestätigt: zwei Datumsfelder und zwei Regime; der Import eines alten Journals geht als Rekonstruktion ein und bleibt dauerhaft so gekennzeichnet. Die Nebenwirkung erwies sich als wichtiger als die Absicht: **Das offene Eingeständnis der Rekonstruktion hebt die Glaubwürdigkeit des übrigen Bestands**, statt sie zu senken.
**Status:** umgesetzt.

### 3. Richtung 3 — Anker machen plausibel, sie messen nicht
**Forschungsfrage.** Welche Rolle kommt maschinellen Spuren (Commits, Dateien, Metadaten) in einer Aufzeichnung zu, deren Gegenstand geistige Arbeit ist?
**Warum schwierig.** Die Versuchung liegt nahe: Wenn ein Commit einen Zeitstempel trägt, soll der Commit die Stunden bestimmen. Das führt zu zwei Unwahrheiten auf einmal. Erstens findet Forschungsarbeit zu großen Teilen abseits des Rechners statt — Analyse, Entwurf, Lektüre — und eine ankergestützte Aufzeichnung sieht sie schlicht nicht. Zweitens bringt ein System, das Anker verlangt, den Menschen bei, **Anker zu produzieren**, und verdirbt damit genau das Material, das Glaubwürdigkeit stiften sollte.
**Stand der Technik (veröffentlicht).** Werkzeuge, die Zeit aus Anwendungsaktivität messen; Aufzeichnungen auf Basis von Repository-Integrationen.
**Erfolgskriterium.** Anker sind plausibilisierende Belege, nie Voraussetzung eines Eintrags; die Stunden bleiben eine Erklärung des Antragstellers; Arbeit abseits des Rechners erhält eine eigene, ausgewiesene Kennzeichnung, statt eine Lücke zu sein.
**Ergebnis.** Als Entwurfsentscheidung bestätigt: Anker (Commits, Beweisdateien) hängen sich automatisch an, wo es sie gibt; ein Eintrag ohne Anker ist vollwertig und als konzeptionelle Arbeit gekennzeichnet. Die konkurrierende Hypothese „Anker als Voraussetzung" wurde verworfen — auf Kosten der bequemeren Erzählung, zugunsten einer Aufzeichnung, die über die Natur der Forschungsarbeit nicht lügt.
**Status:** umgesetzt (konkurrierende Hypothese verworfen).

### 4. Richtung 4 — ein Beweis, der das System überlebt, in dem er entstand
**Forschungsfrage.** Lässt sich die Unveränderbarkeit jemandem zeigen, der keinen Zugang zum System hat — und lässt sie sich noch zeigen, wenn es das System nicht mehr gibt?
**Warum schwierig.** Ein interner Beweis ist so viel wert wie das Vertrauen in den Betreiber; und der Betreiber ist hier zugleich der Begünstigte. Ein externer Beweis verlangt dagegen, dass das, was nach außen geht, keine Inhalte enthält — denn der Inhalt einer Forschungsaufzeichnung ist Betriebsgeheimnis.
**Stand der Technik (veröffentlicht).** Zeitstempel nach RFC 3161, OpenTimestamps mit Verankerung in Bitcoin, Merkle-Bäume und Transparenz-Logs, Ed25519-Signaturen.
**Erfolgskriterium.** Die Woche wird als kanonische Fassung abgeschlossen → SHA-256 → Stempel in **mindestens zwei** Kanälen; die Prüfung ist ohne Zugang zur Instanz und nach deren vollständigem Verlust möglich.
**Ergebnis.** Im Rahmen des Kriteriums bestätigt: kanonische Fassung der Wocheneinträge, Hash, Stempel in einem signierten Log mit Merkle-Baum sowie ein zweiter, unabhängiger OpenTimestamps-Stempel mit Verankerung in Bitcoin; die Nachweise liegen als Dateien neben dem System. **Der Vorbehalt und seine Auflösung.** Der erste Kanal ist unser eigener Zeitdienst — die Signatur des Betreibers allein würde also nichts entscheiden. Die Auflösung ist keine Zusicherung, sondern die Konstruktion: Das Log dieses Dienstes beglaubigt sich nicht selbst, denn die Wurzel jeder abgeschlossenen Woche wird extern verankert — in Bitcoin über OpenTimestamps und im Verwendungszweck einer von einer Bank gebuchten Überweisung, mit veröffentlichter Buchungsreferenz. Eine Grenze bleibt und gehört ausgesprochen: Ein frisch eingereichter Stempel landet in einer noch offenen Woche und wird erst mit deren Abschluss extern verankert. In diesem Fenster trägt der zweite, direkte OpenTimestamps-Stempel, den die Instanz selbst setzt.
**Status:** umgesetzt.

### 5. Richtung 5 — Beweis ohne Offenlegung des Inhalts (Entwurfsänderung)
**Forschungsfrage.** Wie hängt man einem Eintrag Beweismaterial an, das sein Eigentümer niemandem zeigen darf?
**Warum schwierig.** Der ursprüngliche Entwurf sah das Hochladen von Dateien in die Instanz vor: Scans, Geräteausdrucke, Messdaten. Der Aufprall auf die Wirklichkeit kam sofort — für einen Teil der Labore ist bereits der Inhalt dieser Dateien Betriebsgeheimnis, und ihn in irgendein System zu laden, auch in das eigene, ist eine Entscheidung, die sie nicht treffen wollen.
**Stand der Technik (veröffentlicht).** Kryptographische Commitments, reine Hash-basierte Existenznachweise, Hashberechnung im Browser.
**Erfolgskriterium.** Eine Variante, in der die Instanz die Datei nie sieht und ihr Hash dennoch unter den Wochenzeitstempel gerät.
**Ergebnis.** Als **Entwurfsänderung** bestätigt: Neben dem Upload-Modus existiert der Hash-only-Modus — der Browser berechnet SHA-256 lokal, in das System gelangt allein der Fingerabdruck. Ausdrückliche Randbedingung: Ein solcher Beweis ist ohne das Original wertlos. Die Prüfung besteht darin, die Datei vorzulegen und den Hash zu vergleichen; wer das Original verliert, behält eine Zahl, die nichts belegt. Das ist der Preis, den man für die Nichtoffenlegung bewusst zahlt.
**Status:** umgesetzt (beide Modi, in der Instanzkonfiguration umschaltbar).

### 6. Richtung 6 — eine Aufzeichnung, die sich selbst begrenzt
**Forschungsfrage.** Kann eine Aufzeichnung eigene Stunden aktiv abschneiden — und stärkt ein solcher Schnitt ihre Glaubwürdigkeit?
**Warum schwierig.** Eine Aufzeichnung, in der jede Woche punktgenau am Maximum endet, ist für jeden Leser ein Warnzeichen — und zugleich das natürliche Ergebnis eines Systems, das die Grenze einfach nicht überschreiten lässt. Arbeit oberhalb der Grenze existiert wirklich; sie aus der Aufzeichnung zu drängen heißt Material zu verlieren, sie in die Grenze hineinzuschreiben heißt zu lügen.
**Stand der Technik (veröffentlicht).** Die Methodik der Forschungszulage mit einer Wochengrenze je Person; die Praxis der Arbeitszeiterfassung mit harten Validierungen.
**Erfolgskriterium.** Stunden oberhalb der Grenze werden erfasst und sind sichtbar, aber ausdrücklich als **nicht abgerechnet** gekennzeichnet; Routinearbeit wird dokumentiert und ausdrücklich von der Forschung abgegrenzt; die Grenze ist je Person einstellbar, denn Beschäftigungsumfänge sind nicht gleich.
**Ergebnis.** Bestätigt: drei getrennte Kennzeichnungen (abgerechnete Forschung, Forschung oberhalb der Grenze — nicht abgerechnet, Routinearbeit außerhalb des Umfangs), Wochengrenze je Konto, Anker für alle drei Kategorien. Nebenbei löst das die Kontinuitätsfrage: Wochen ohne Forschungsarbeit sind keine Löcher im Kalender mehr.
**Status:** umgesetzt.

### 7. Richtung 7 — Teamarbeit ohne Einblick in die Stunden der anderen
**Forschungsfrage.** Wie führt man eine gemeinsame Projektaufzeichnung, ohne den Mitarbeitenden wechselseitig ihre Arbeitszeit zu zeigen?
**Warum schwierig.** Der Bericht für die prüfende Stelle muss vollständig sein — nach Personen aufgeschlüsselt und mit Summen. Die Sicht der Mitarbeitenden sollte den Arbeitsumfang der Kollegen nicht offenlegen, denn das ist eine Information mit Entgeltcharakter. Beide Anforderungen treffen in einem Datenbestand und in einem Export aufeinander.
**Erfolgskriterium.** Vollständigkeit des Gesamtberichts bei gleichzeitiger Maskierung der Stunden zwischen Personen — auch in den Ausgabedateien, nicht nur am Bildschirm.
**Ergebnis.** Bestätigt: nach Personen aufgeschlüsselter Bericht für die Leitung, Maskierung zwischen Mitarbeitenden in Ansichten und Exporten, Autorschaft je Eintrag. Randbedingung: Maskierung schützt vor Einblick, nicht vor Rückschluss — wer die Teamgröße und die Gesamtsumme kennt, rekonstruiert einen Teil der Information rechnerisch.
**Status:** umgesetzt.

**Status der Richtung.** Alle sieben Richtungen liegen umgesetzt und in Betrieb vor. Das Ergebnis, das über dieses Feld hinauszuweisen scheint, ist die Beobachtung aus den Richtungen 2, 3 und 6: **Die Glaubwürdigkeit einer Aufzeichnung wächst dort, wo sie ihre eigenen Grenzen offen einräumt** — die Rekonstruktion, den fehlenden Anker, die Stunden, die nicht gezählt werden dürfen. Nächster Forschungsschritt: das Lesezugriffs-Journal als eigenständiges Beweismaterial (wer wann welchen Bericht sah) sowie die Verschlüsselung der Anker im Ruhezustand ohne Verlust der Prüfbarkeit des Zeitstempels.

---
---

# 🇬🇧 ENGLISH VERSION

## Koch Laboratory — records meant to convince someone who does not trust their author

A record of research working time is a peculiar kind of document: it is written by the party who benefits from it and read by someone who professionally assumes it could have been produced yesterday. The entire technical difficulty flows from that asymmetry — not from counting hours. This direction asks what properties a record must have for its credibility not to depend on the good will of its author, and where the limits of what can be shown at all actually lie.

**Method.** Problem → hypothesis → falsifiable criterion → result with boundary conditions. Statuses are stated openly; design changes forced by contact with reality appear as changes, not smoothed over after the fact.

### 1. Direction 1 — a record with nothing to correct
**Research question.** Can records be kept so that the impossibility of amending an entry is a property of the system rather than a declaration by its user?
**Why it is hard.** From the reader's point of view, any system that permits editing is the same thing as a spreadsheet — yet people make mistakes and must correct them. A ban on editing without a correction mechanism is untenable in practice; a correction mechanism without a trace defeats the whole purpose.
**State of the art (published).** Immutability requirements in tax law (GoBD, § 146 of the German fiscal code), the accounting principle of storno, WORM media and storage, event-sourced systems.
**Success criterion.** After a week is closed, no path exists to edit or delete an entry; a correction is a **new entry** pointing at the corrected one, and the original stays visible.
**Result.** Confirmed: closed entries are immutable, corrections are storno entries with a reference, deletion is blocked. Boundary condition: the property belongs to the record, not to the medium — whoever holds administrative access to the database holds access to the database; evidentially that is defended only by direction 4, not by application rules. We say so explicitly, because systems that call themselves "immutable by design" usually do not.
**Status:** implemented.

### 2. Direction 2 — two dates instead of one
**Research question.** How do you record work done three months ago without pretending the record was written back then?
**Why it is hard.** Records reconstructed after the fact carry less evidential weight than contemporaneous ones, yet they are unavoidable: laboratories only start documenting systematically at some point, and the earlier work really happened. A system that lets you enter a work date with no trace of when the entry was made turns the whole record into a body of uniformly unverifiable quality.
**State of the art (published).** The separation of event time and recording time in bitemporal databases; the "zeitnah" (contemporaneous) requirement in the research allowance methodology.
**Success criterion.** Work date and recording date are separate fields, the second assigned automatically; the recording regime (contemporaneous / reconstruction) is explicit and survives the import of old material.
**Result.** Confirmed: two date fields and two regimes; the import of an old journal enters as reconstruction and stays marked that way permanently. The side effect proved more important than the intent: **openly admitting to reconstruction raises the credibility of the rest of the record** instead of lowering it.
**Status:** implemented.

### 3. Direction 3 — anchors make entries plausible; they do not measure them
**Research question.** What is the proper role of machine traces (commits, files, metadata) in a record whose subject is intellectual work?
**Why it is hard.** The temptation is obvious: if a commit carries a timestamp, let the commit determine the hours. That produces two falsehoods at once. First, a large part of research work happens away from the computer — analysis, design, reading — and an anchor-driven record simply cannot see it. Second, a system that demands anchors teaches people to **produce anchors**, spoiling the very material that was supposed to lend credibility.
**State of the art (published).** Tools that infer time from application activity; records built on repository integrations.
**Success criterion.** Anchors are corroborating evidence, never a precondition for an entry; hours remain a declaration by the applicant; work away from the computer gets its own explicit marking instead of being a gap.
**Result.** Confirmed as a design decision: anchors (commits, evidence files) attach automatically where they exist, and an entry without an anchor is fully valid and marked as conceptual work. The competing hypothesis, "anchor as a precondition", was rejected — at the cost of the more convenient narrative, in favour of a record that does not lie about the nature of research work.
**Status:** implemented (competing hypothesis rejected).

### 4. Direction 4 — proof that outlives the system it was made in
**Research question.** Can immutability be demonstrated to someone with no access to the system — and still be demonstrated once the system no longer exists?
**Why it is hard.** An internal proof is worth exactly as much as trust in the operator; and here the operator is also the beneficiary. An external proof, on the other hand, requires that whatever leaves the premises contain no content — because the content of a research record is a trade secret.
**State of the art (published).** RFC 3161 timestamps, OpenTimestamps anchored in Bitcoin, Merkle trees and transparency logs, Ed25519 signatures.
**Success criterion.** A week is closed as a canonical record → SHA-256 → a stamp in **at least two** channels; verification possible without access to the instance and after its total loss.
**Result.** Confirmed within the criterion: a canonical form of the week's entries, a hash, a stamp in a signed log with a Merkle tree, and a second, independent OpenTimestamps stamp anchored in Bitcoin; the proofs sit as files beside the system. **The caveat and how it is answered.** The first channel is our own time service — the operator's signature alone would therefore settle nothing. The answer is not a reassurance but the construction: that service's log does not attest to itself, because the root of every closed week is anchored externally — in Bitcoin via OpenTimestamps, and in the reference line of a transfer booked by a bank, with the booking reference published. One boundary remains and deserves saying: a freshly submitted stamp lands in a week that is still open and becomes externally anchored only once that week closes. In that window the entry is carried by the second, direct OpenTimestamps stamp, made by the instance itself.
**Status:** implemented.

### 5. Direction 5 — proof without disclosing content (a design change)
**Research question.** How do you attach evidence to an entry when its owner may not show that evidence to anyone?
**Why it is hard.** The original design assumed files uploaded into the instance: scans, instrument printouts, measurement data. The collision with reality was immediate — for some laboratories the very content of those files is a trade secret, and putting them into any system, including their own, is a decision they do not want to take.
**State of the art (published).** Cryptographic commitments, existence proofs resting on hashes alone, computing the hash in the browser.
**Success criterion.** A variant in which the instance never sees the file, yet its hash still goes under the weekly timestamp.
**Result.** Confirmed as a **design change**: alongside the upload mode there is a hash-only mode — the browser computes SHA-256 locally and only the fingerprint reaches the system. Boundary condition stated openly: such a proof is worthless without the original. Verification means producing the file and comparing the hash; whoever loses the original is left with a number that proves nothing. That is the price knowingly paid for not disclosing content.
**Status:** implemented (both modes, switchable in the instance configuration).

### 6. Direction 6 — records that cap themselves
**Research question.** Can a record actively cut its own hours — and does such a cut strengthen its credibility?
**Why it is hard.** A record in which every week ends exactly at the maximum is a warning sign to any reader — and at the same time the natural output of a system that simply refuses to exceed the limit. Work above the limit really happens; pushing it out of the record loses material, while writing it inside the limit is untrue.
**State of the art (published).** The research allowance methodology with a weekly cap per person; time-recording practice with hard validations.
**Success criterion.** Hours above the cap are recorded and visible, but explicitly marked as **not claimed**; routine work is documented and explicitly demarcated from research; the cap is set per person, because contracted hours differ.
**Result.** Confirmed: three separate markings (claimed research, research above the cap — not claimed, routine work out of scope), a weekly cap per account, anchors attached across all three categories. As a side effect this settles the continuity question: weeks without research work stop being holes in the calendar.
**Status:** implemented.

### 7. Direction 7 — team work without seeing each other's hours
**Research question.** How do you keep a shared project record without showing employees each other's working time?
**Why it is hard.** The report for the assessing body must be complete — broken down by person and with totals. The employee's view should not reveal colleagues' workload, because that is information of a salary nature. Both requirements meet in one dataset and in one export.
**Success criterion.** Completeness of the aggregate report together with masking of hours between people — in the output files as well, not only on screen.
**Result.** Confirmed: a per-person breakdown for the lead, masking between employees in views and exports, authorship recorded on every entry. Boundary condition: masking protects against inspection, not against inference — anyone who knows the size of the team and the aggregate total can reconstruct part of the information arithmetically.
**Status:** implemented.

**Status of the direction.** All seven directions are implemented and running. The result that seems to reach beyond this field is the observation from directions 2, 3 and 6: **the credibility of a record grows where the record openly admits its own limits** — the reconstruction, the missing anchor, the hours that must not be counted. Next research step: the read-access journal as evidence in its own right (who viewed which report and when), and encryption of anchors at rest without losing the verifiability of the timestamp.