Przepisanie StatCraft w Rust rzuca wyzwanie IBM SPSS, oferując inne podejście do bezpieczeństwa

Twórca StatCraft przedstawia go jako tworzoną samodzielnie alternatywę dla IBM SPSS Statistics, opartą na deklaracji użycia w 100% Safe Rust. Przepisanie StatCraft w Rust stawia obietnicę inżynieryjną w centrum projektu oprogramowania statystycznego: mniej niebezpiecznych awarii, gdy badacze pracują z trudnymi danymi. To, czy obietnica ta przełoży się na wiarygodne analizy, pozostaje odrębną kwestią.

To rozróżnienie ma znaczenie, ponieważ zastąpienie oprogramowania statystycznego oznacza przejęcie odpowiedzialności za wnioski, które ludzie na jego podstawie wyciągają. Program może prawidłowo zarządzać pamięcią, a jednocześnie wybrać niewłaściwe obserwacje, błędnie interpretować brakujące wartości lub obliczyć mylący wynik. Badacze potrzebują niezawodnego działania w całym tym łańcuchu.

Publiczny projekt i towarzysząca mu dyskusja potwierdzają ambitne przedsięwzięcie rozwojowe, a nie wykazaną równoważność z produktem IBM. Jego główne napięcie jest jasne: zabezpieczenia językowe ograniczają ryzyko implementacyjne, natomiast zaufanie statystyczne wymaga dowodów dotyczących obliczeń, zgodności i wyborów analitycznych.

Co faktycznie zapowiada przepisanie StatCraft w Rust

StatCraft to niezależnie rozwijana alternatywa ukierunkowana na przepływy pracy SPSS, a nie ogłoszony przez IBM zamiennik.

Twórca przedstawił inicjatywę w zgłoszeniu na Hacker News, opisując ją jako samodzielne przepisanie. To sformułowanie oddaje skalę ambicji, lecz czytelnicy powinni odróżniać nagłówek od relacji między produktami. W przeanalizowanych materiałach nie ma podstaw, by przedstawiać to jako partnerstwo z IBM lub oficjalny projekt migracyjny.

Repozytorium StatCraft opisuje otwartoźródłowy pakiet statystyczny z interfejsem graficznym i sterowanym poleceniami silnikiem analitycznym. Wymienia znane procedury, w tym statystykę opisową, testy porównujące średnie oraz analizę wariancji, która porównuje zmienność wewnątrz i między grupami.

Projekt opisuje również obsługę wyników i składni w stylu SPSS. Składnia oznacza tu pisemne polecenia określające analizę, a nie działania wykonywane wyłącznie za pomocą menu. Te znajome elementy wskazują, które nawyki pracy twórca chce zachować.

Są to opisy projektu, a nie niezależne ustalenia z zakończonej oceny oprogramowania. Ten artykuł nie zweryfikował niezależnie deklarowanego zakresu funkcji, dokładności liczbowej ani gwarancji braku awarii. Publiczna implementacja umożliwia badanie, ale sama publikacja nie potwierdza gotowości.

Manifest workspace zapewnia bardziej konkretny obraz struktury inżynieryjnej. Wskazuje wersję 0.3.0 i rozdziela komponenty dotyczące obliczeń, obsługi danych, składni, raportowania, aplikacji oraz mostu agenta. Taka organizacja daje recenzentom rozpoznawalne granice do sprawdzenia.

Granice te są istotne, ponieważ błąd statystyczny może pojawić się jeszcze przed uruchomieniem formuły. Nieprawidłowe zaimportowanie wartości może podważyć skądinąd poprawne obliczenie. Niejednoznaczne sformatowanie wyniku może podważyć skądinąd poprawną interpretację. Zamiennik musi zapewnić zgodność w całym przepływie pracy.

Czytany jako wyjaśnienie StatCraft na podstawie jego publicznych materiałów, projekt łączy znaną interakcję statystyczną z odmienną strategią implementacji. Twórca chce, aby badacze zachowali rozpoznawalne przepływy pracy, jednocześnie zyskując bardziej jednoznaczną obsługę nieprawidłowych danych wejściowych.

To istotny kierunek produktowy, który nie przesądza o wyniku rynkowym. Dostępne dowody nie wskazują, że instytucje migrują, że IBM mierzy się z natychmiastową presją komercyjną ani że StatCraft kompleksowo obejmuje SPSS. Wymagałoby to dodatkowych dowodów.

Zmiana jest zatem węższa i bardziej użyteczna niż deklaracja, że obecny lider został zastąpiony. Twórca udostępnił alternatywną implementację do wglądu. Projekt zaprasza teraz do sprawdzenia, czy jego wybory inżynieryjne przekładają się na wiarygodne zachowanie w badaniach.

Dla czytelników śledzących zapowiedź to rozróżnienie zapobiega wyprzedzaniu dowodów przez oczekiwania. Ambitne repozytorium może zasługiwać na uwagę, podczas gdy jego najmocniejsze obietnice nadal pozostają nierozstrzygnięte. Następne pytanie brzmi, którzy użytkownicy skorzystaliby, gdyby te obietnice wytrzymały analizę.

Badacze ponoszą koszt zmiany

Bezpośredni ciężar spoczywa na każdym, kto ocenia StatCraft, ponieważ znajome elementy sterowania nie zapewniają wymienności wyników.

Rozważmy hipotetyczny zespół badawczy na uczelni, który ponownie analizuje wyniki ankiety. Jego obecny przepływ pracy obejmuje zbiór danych, pisemne polecenia, opisy zmiennych i wyniki wykorzystane w raporcie. Zamiennik musi zachować znaczenie tych materiałów, a nie tylko wyświetlać podobne ekrany.

Zespół musiałby wiedzieć, czy do każdego obliczenia trafiają te same obserwacje. Musiałby również zrozumieć, jak zamiennik traktuje pytania bez odpowiedzi, etykiety kategorii i wszelkie transformacje zastosowane przed analizą. Różnice na tych etapach mogą zmienić wniosek.

W tym miejscu porównanie StatCraft kontra SPSS staje się praktyczne. Badacz oceniający zamiennik potrzebuje jasnego opisu obsługiwanego zachowania i znanych różnic. Atrakcyjny interfejs nie odpowie na pytanie, czy istniejącą analizę da się wiernie odtworzyć.

Koszt zmiany wykracza również poza osobę uruchamiającą oprogramowanie. Promotor może potrzebować przejrzeć polecenia. Współpracownik może potrzebować skontrolować wyniki. Przyszły badacz może potrzebować odtworzyć sposób, w jaki powstało opublikowane ustalenie.

Wymagania te tworzą obciążenie dokumentacyjne dla twórcy StatCraft. Użyteczny opis funkcji wyjaśnia, co robi polecenie, jakie dane wejściowe akceptuje i jak obsługuje sytuacje wyjątkowe. Wyjaśnia także, gdzie zachowanie różni się od produktu, który przypomina.

Dla potencjalnego użytkownika najbezpieczniejsza wstępna ocena obejmowałaby niewrażliwe kopie znanej pracy o znanych wynikach. Pozwoliłoby to ujawnić rozbieżności bez czynienia nowej aplikacji odpowiedzialną za niezastępowalny zapis badawczy. Taka ocena dostarczyłaby dowodów dotyczących konkretnego przepływu pracy.

Pomyślne porównanie nadal miałoby ograniczenia. Zgodność w prostym zbiorze danych zwiększałaby zaufanie do tego przykładu, a nie do każdej procedury czy danych wejściowych. Szersze zaufanie wymagałoby porównań obejmujących różne warunki danych i opcje analityczne.

Nakłada to asymetryczny ciężar na pretendenta. Ugruntowany przepływ pracy ma już historię w organizacji, która go stosuje, nawet jeśli zasługuje on na ulepszenie. Nowy uczestnik musi wyjaśnić zarówno swoje korzyści, jak i koszt weryfikacji swojego działania.

Presja na obecne oprogramowanie jest zatem warunkowa. Jeśli mniejsza alternatywa sprawia, że obsługa błędów jest bardziej przejrzysta, a migracja łatwiejsza do sprawdzenia, użytkownicy zyskują konkretną podstawę do porównania. To mogłoby zakwestionować oczekiwania co do tego, jak aplikacje statystyczne powinny wyjaśniać swoje decyzje.

Nic w zapowiedzi nie potwierdza, że stało się to na skalę instytucjonalną. Obecna presja jest pytaniem ewaluacyjnym: czy pretendent może zmniejszyć frustrację operacyjną bez zwiększania niepewności co do wyników? Pytanie to prowadzi bezpośrednio do ograniczeń obietnicy związanej z Rust.

Safe Rust rozwiązuje określoną klasę awarii

Bezpieczeństwo pamięci wzmacnia implementację, lecz nie poświadcza statystycznego znaczenia jej wyników.

Safe Rust to część Rust regulowana jego standardowymi ograniczeniami bezpieczeństwa, w tym kontrolami dostępu do pamięci. Bezpieczeństwo pamięci dotyczy tego, czy oprogramowanie uzyskuje dostęp do przechowywanych danych poprzez prawidłowe operacje. Nie przesądza, czy aplikacja implementuje zamierzoną metodę analityczną.

Rozróżnienie to jest wyraźnie opisane w dokumentacji samego Rust. Jej omówienie unsafe operations wyjaśnia, które operacje wymagają dodatkowej odpowiedzialności programistów. Stwierdza również, że zachowanie uznawane za bezpieczne może nadal obejmować wycieki pamięci, zakleszczenia i zakończenie programu.

Zakleszczenie występuje, gdy wykonywanie przestaje postępować, ponieważ zadania oczekują na siebie nawzajem w nieskończoność. Ten przykład pokazuje, dlaczego „bezpieczny” ma precyzyjne znaczenie techniczne. Czytelnicy nie powinni rozszerzać go na obietnicę zniknięcia każdej możliwej awarii.

W oprogramowaniu statystycznym prawidłowa operacja pamięci może nadal pobrać niewłaściwą kolumnę. Poprawnie zarządzana kolekcja może nadal zawierać obserwacje wybrane według błędnej reguły. Obliczenie może zostać wykonane bez błędu pamięci, a mimo to odpowiadać na inne pytanie niż to postawione przez badacza.

Te możliwości nie umniejszają wartości zabezpieczeń językowych. Określają, gdzie kończy się ich zakres. Zapobieganie problemowi implementacyjnemu zwalnia uwagę dla innych problemów, ale nie rozwiązuje ich automatycznie.

Nacisk StatCraft na jawne błędy wpisuje się w tę węższą interpretację. Gdy operacja nie może wygenerować sensownego wyniku, aplikacja powinna jasno zakomunikować ten stan. Użyteczność takiego zachowania zależy od tego, czy oprogramowanie prawidłowo rozpoznaje dany warunek.

Wyobraźmy sobie hipotetyczne porównanie, w którym każda zarejestrowana wartość jest identyczna. Aplikacja powinna wyjaśnić, co oznacza to dla żądanego obliczenia. Zwrócenie błędu, wygenerowanie ograniczonego wyniku i ciche kontynuowanie tworzyłyby odmienne doświadczenia badawcze.

Istotne pytanie dotyczy zatem obserwowalnego zachowania. Czy aplikacja zachowuje pracę użytkownika, gdy odrzuca dane wejściowe? Czy dokładnie wyjaśnia odrzucenie? Czy recenzent może ustalić, która operacja zakończyła się niepowodzeniem i czy wcześniejsze transformacje nadal pozostają aktywne?

Przepisanie StatCraft w Rust zasługuje na ocenę według tych pytań, zamiast zakładać, że wybór języka je rozstrzyga. Jasna demonstracja odzyskiwania po błędzie wspierałaby konkretną deklarację niezawodności. Sama etykieta języka nie byłaby wystarczająca.

Ta sama ostrożność dotyczy bezwzględnych obietnic braku awarii. Warunki działania, zależności, limity zasobów i logika aplikacji wpływają na zachowanie. Artykuł nie powinien przekształcać zamierzonej dyscypliny projektowej twórcy w niezależnie potwierdzoną gwarancję.

Istnieje także różnica między kodem projektu a szerszym oprogramowaniem, którego on używa. Deklaracja dotycząca unikania bloków unsafe wymaga jasno zdefiniowanego zakresu. Recenzenci powinni wiedzieć, czy obejmuje ona kod aplikacji, zależności czy kompletny rozpowszechniany plik wykonywalny.

Zakres ten ma znaczenie przy porównywaniu implementacji. W przeciwnym razie czytelnicy ryzykują porównanie wąskiej polityki dotyczącej kodu źródłowego ze znacznie szerszym twierdzeniem o niezawodności produktu. Użyteczna ocena opisałaby zarówno politykę, jak i awarie faktycznie zbadane w testach.

Najsilniejszy argument projektu ma zatem charakter testowalny: jawne ograniczenia i obsługa błędów powinny ułatwiać zapobieganie określonym awariom lub ich diagnozowanie. Zaufanie statystyczne nadal zależy od formuł, semantyki danych i walidacji otaczającej te wybory inżynieryjne.

StatCraft kontra SPSS wykracza poza interfejs

Wiarygodne porównanie musi uwzględniać utrwalone możliwości analityczne oraz konkurencyjne podejścia do automatyzacji.

Platforma analiz statystycznych firmy IBM obejmuje przygotowanie danych, testy statystyczne, modelowanie predykcyjne, regresję i prognozowanie. IBM reklamuje również AI Output Assistant, który wyjaśnia wyniki za pomocą języka naturalnego.

Ten kontekst ogranicza wszelkie twierdzenia, że StatCraft wkracza w pustą niszę. IBM już przedstawia interpretację wspieraną przez AI jako element kierunku rozwoju swojego produktu. Proponowane wyróżnienie StatCraft musi więc opierać się na jego konkretnej architekturze i działaniu.

Bardziej użyteczne porównanie dotyczy odpowiedzialności w całym procesie analitycznym. Które elementy określa użytkownik? Które wybiera oprogramowanie? Które decyzje pozostają później widoczne? Te pytania dotyczą zarówno konwencjonalnych interfejsów, jak i tych pośredniczonych przez AI.

Integracja agentów w StatCraft opisuje obsługę Model Context Protocol, standardowego interfejsu, za pośrednictwem którego aplikacje AI uzyskują dostęp do narzędzi i danych. Według informacji o wydaniu agenci mogą analizować zmienne, wczytywać zestawy danych i wykonywać polecenia analityczne.

Informacje o wydaniu opisują także połączenie z uruchomioną aplikacją graficzną. Tworzy to proponowany przepływ pracy, w którym asystent konwersacyjny zleca operacje, a silnik statystyczny wykonuje obliczenia. Publiczna dokumentacja potwierdza zamierzony projekt, a nie niezależnie zweryfikowaną niezawodność działania od początku do końca.

To rozdzielenie ma sens analityczny. Model językowy nie powinien zastępować silnika obliczeniowego wymyśloną arytmetyką. Korzystanie z silnika obliczeniowego nie potwierdza jednak, że model zlecił właściwą operację.

Asystent może wybrać nieodpowiednie porównanie i otrzymać poprawnie obliczony wynik. Może błędnie rozumieć znaczenie zmiennej, przekazując jednocześnie prawidłowe polecenia. Może też przedstawiać zależność jako silniejszy dowód, niż uzasadnia badanie.

Dla użytkowników wartościową funkcją byłby możliwy do sprawdzenia zapis łączący żądanie z dokładnie wykonanymi operacjami. Taki zapis powinien ujawniać wybór zmiennych, przekształcenia, wykluczenia i ustawienia analityczne. W przeciwnym razie wygoda rozmowy może ukrywać decyzje, które wcześniej były widoczne w zapisanych poleceniach.

Komplikuje to również twierdzenia dotyczące prywatności. Obliczenie wykonywane lokalnie określa, gdzie odbywa się to obliczenie. Nie określa jednak, gdzie podłączony asystent przetwarza prompty, opisy zmiennych, podglądy lub zwracane wyniki.

Osoby oceniające powinny zatem sprawdzić skonfigurowanego asystenta oraz informacje, które otrzymuje. Lokalne połączenie jest jednym szczegółem architektonicznym w pełnym przepływie danych. Badacze pracujący z poufnymi materiałami potrzebują dowodów obejmujących całą tę ścieżkę.

Szersze pytanie StatCraft vs SPSS dotyczy zatem niezawodnej kontroli, a nie tego, który produkt ma najnowocześniejszy styl interakcji. Pomoc AI staje się użyteczna, gdy użytkownicy mogą sprawdzać, odtwarzać i kwestionować operacje stojące za odpowiedzią.

Zespołom porównującym takie zapisy przeszukiwalna baza wiedzy może zapewnić dostępność specyfikacji i ustaleń z oceny. Wyszukiwanie dokumentacji wspiera przegląd, podczas gdy walidacja numeryczna pozostaje obowiązkiem oceny analitycznej.

Wniosek konkurencyjny pozostaje wyważony. StatCraft zaproponował architekturę wartą zbadania. Udokumentowany zakres IBM pokazuje, dlaczego zastąpienie pakietu statystycznego wymaga czegoś więcej niż dopasowania rozpoznawalnego interfejsu lub dodania połączenia z asystentem.

Publiczna debata koncentruje się na dowodach

Najpoważniejsza krytyka dotyczy luki między deklaracjami dotyczącymi implementacji a niezależnie odtwarzalnym działaniem analitycznym.

Debata o poprawności statystycznej obejmuje różne stanowiska. Twórca podkreśla unikanie utraty pracy i obsługę trudnych danych wejściowych. Przychylni komentatorzy cenią alternatywy dla narzędzi własnościowych. Sceptycy kwestionują, czy Rust rozwiązuje błędy, które mają największe znaczenie w analizie statystycznej.

Stanowiska te nie muszą się wzajemnie wykluczać. Lepsza obsługa nieprawidłowych danych wejściowych byłaby korzystna dla badaczy. Bardziej dostępne alternatywy również przyniosłyby korzyści użytkownikom, którzy ich potrzebują. Żadne z tych twierdzeń nie potwierdza, że ta konkretna implementacja zapewnia niezawodne wyniki.

Szczególnie istotny głos należał do komentatora przedstawiającego się jako autor PSPP, Ben Pfaff. Opisał on formaty plików SPSS jako trudny problem kompatybilności i stwierdził, że również przepisuje PSPP w Rust. Są to przypisane wypowiedzi z dyskusji.

Jego wypowiedź umieszcza wyzwanie w szerszym kontekście inżynieryjnym. Odtworzenie przepływów pracy wymaga zrozumienia przechowywanych informacji, a także implementacji formuł. Plik może zawierać znaczenia, które łatwo utracić, gdy zamiennik skupia się na widocznych wartościach.

Ta obserwacja sugeruje wymagający standard oceny. Zamiennik powinien uwzględniać informacje, które zachowuje, informacje, które przekształca, oraz informacje, których nie potrafi interpretować. Cicha utrata byłaby bardziej niepokojąca niż jasne wskazanie nieobsługiwanego zachowania.

Dyskusja zawiera również krytykę rozwoju wspomaganego przez AI. Komentarze te wyrażają oceny dotyczące metod tworzenia oprogramowania, a nie niezależnie potwierdzają sposób powstania każdego komponentu. Indywidualne przedstawienie zgłoszenia również nie dowodzi, że twórca pracował bez pomocy oprogramowania.

Dla czytelników spory o autorstwo są mniej rozstrzygające niż dowody dotyczące przeglądu i działania. Projekt jednoosobowy może publikować jasne testy i przyciągać kompetentną kontrolę. Większy projekt także może zawierać błędy. Wielkość zespołu zmienia kwestie utrzymania, ale nie przesądza o poprawności.

Użyteczny zapis walidacyjny łączyłby dane wejściowe z dokładnie żądaną operacją i oczekiwanym wynikiem. Wyjaśniałby obliczenie referencyjne i uzasadniał każdą dopuszczalną różnicę. Recenzenci mogliby wtedy odróżnić zamierzoną konwencję od błędu implementacji.

Jest to szczególnie ważne, gdy projekt deklaruje zgodność z innym pakietem. Zgodność wybranych wyników wspiera ograniczony wniosek dotyczący tych przykładów. Nie potwierdza pełnej równoważności dla każdej opcji, zestawu danych ani warunku wyjątkowego.

Różnice również zasługują na wyjaśnienie, a nie automatyczne potępienie. Aplikacje statystyczne mogą odmiennie implementować udokumentowane konwencje. Zamiennik staje się łatwiejszy do oceny, gdy wyraźnie wskazuje te wybory i pokazuje ich praktyczne konsekwencje.

Utrzymanie rodzi odrębną kwestię. Użytkownicy muszą wiedzieć, jak nieprawidłowe wyniki będą zgłaszane, poprawiane i komunikowane. Poprawka powinna pomóc ustalić, czy wcześniejsza praca wymaga przeglądu, zamiast jedynie zmieniać przyszłe wyniki.

Dla indywidualnego twórcy odpowiedzialność ta jest znacząca. Obejmuje dokumentację, obsługę zgłoszeń i zachowanie wystarczającej historii do badania rozbieżności. Udział społeczności byłby pomocny, lecz sam udział wymaga dowodów wykraczających poza zainteresowanie ogłoszeniem.

Właściwą oceną nie jest zatem ani automatyczne odrzucenie, ani akceptacja najsilniejszych obietnic. Publiczny projekt oferuje coś, co można sprawdzić. Zaufanie powinno rosnąć proporcjonalnie do szczegółowości, zakresu i niezależności dowodów wytwarzanych wokół niego.

Trzy sygnały określą wiarygodność projektu

Najbardziej informatywne kolejne wydarzenia dotyczą odtwarzalnych obliczeń, udokumentowanej kompatybilności i korzystania z projektu przez osoby spoza niego.

W nadchodzących miesiącach pierwszym sygnałem będzie publiczny zapis walidacji, który inne osoby będą mogły ponownie uruchomić. Najmocniejsze przykłady łączyłyby zestaw danych, żądanie analityczne, oczekiwany wynik oraz wyjaśnienie punktu odniesienia.

Uczyniłoby to twierdzenia numeryczne konkretnymi. Recenzenci mogliby sprawdzać trudne dane wejściowe obok zwykłych i zobaczyć, czy awarie dają użyteczne wyjaśnienia. Opublikowane rozbieżności pokazałyby również, czy projekt traktuje walidację jako dochodzenie, a nie promocję.

Takie dowody wzmocniłyby zaufanie do procedur, których dotyczą. Ich brak pozostawiłby szerokie twierdzenia o dokładności zależne od relacji twórcy. To rozróżnienie powinno pozostać widoczne, nawet jeśli interfejs stanie się bardziej dopracowany.

Drugim sygnałem będzie jasna granica kompatybilności. Czytelnicy powinni zwracać uwagę na dokumentację wskazującą obsługiwane polecenia, akceptowane zachowanie plików oraz znane różnice. Krótkie, precyzyjne wyjaśnienie byłoby bardziej informatywne niż szerokie twierdzenie o zastąpieniu.

Dokumentacja kompatybilności uczyniłaby także dyskusje o migracji bardziej uczciwymi. Potencjalny użytkownik mógłby ustalić, czy konkretny przepływ pracy mieści się w obsługiwanym zakresie. Nieobsługiwane zachowanie stałoby się wyraźnym problemem oceny zamiast nieprzyjemnym odkryciem.

Ten sygnał wzmocniłby argument za ukierunkowanym wdrożeniem, nawet bez pełnej zgodności. Z kolei rozszerzanie deklaracji bez odpowiedniej dokumentacji utrudniłoby ocenę projektu. Dyscyplina zakresu byłaby dowodem dojrzałości.

Trzecim sygnałem będzie niezależne użycie, które przynosi szczegółowe informacje zwrotne. Najcenniejsze raporty opisywałyby, czego użytkownicy próbowali, którą wersję oceniali, co odpowiadało oczekiwaniom i co wymagało korekty. Takie raporty dostarczałyby dowodów wykraczających poza przykłady twórcy.

Udział osób z zewnątrz byłby szczególnie ważny dla utrzymania. Odtwarzalny raport błędu, po którym następuje wyjaśniona poprawka, ujawniłby, jak projekt radzi sobie z niepewnością. Pokazałby również, czy recenzenci mogą skutecznie angażować się w implementację.

Żaden z tych sygnałów nie wymaga, aby StatCraft natychmiast zastąpił cały ugruntowany pakiet. Węższa aplikacja z wyraźnymi ograniczeniami nadal może być użyteczna. Jej wiarygodność zależałaby od dopasowania obietnic do dowodów oraz od zrozumiałości tych ograniczeń.

Przepisanie StatCraft w Rust warto więc obserwować jako próbę połączenia znanych przepływów pracy statystycznej z wyraźnymi ograniczeniami inżynieryjnymi. Jego znaczenie będzie zależeć od tego, czy takie połączenie przyniesie obserwowalne korzyści bez zaciemniania niepewności analitycznej.

Dla twórców użytecznym wkładem jest odtwarzalny test, udokumentowana rozbieżność lub staranna recenzja obsługiwanej procedury. Dla badaczy użyteczne pytanie brzmi, czy znana analiza pozostaje zrozumiała i powtarzalna po przeniesieniu jej do nowego narzędzia. Porównuj niepoufne przykłady, zachowuj oryginalny przepływ pracy i zapisuj każdą istotną różnicę. Pytaj, które obserwacje weszły do obliczenia, jakie założenia nim rządziły oraz jak niezależny recenzent odtworzyłby wynik. Traktuj zgodność jako dowód w ramach przetestowanego zakresu i badaj rozbieżności, zanim oprzesz się na wyniku. Śledź projekt pod kątem tego, co ujawniają jego implementacja i walidacja. Obietnica zasługuje na kontrolę, która łączy zachowanie oprogramowania z wnioskami badawczymi, którym ludzie rzeczywiście muszą zaufać.