Poziomy pewności danych technicznych — źródło, dowód i wniosek

Etykieta pewności nie opisuje prestiżu całego artykułu ani reputacji autora. Dotyczy konkretnego twierdzenia: określony obiekt miał daną właściwość, wartość albo konfigurację w wskazanych warunkach i czasie. W jednym profilu UAV wymiary mogą być potwierdzone rysunkiem producenta, zasięg deklarowany przez producenta, masa oszacowana ze zdjęć i fragmentów, a rodzaj sensora nadal niepotwierdzony.

Najczęstszy błąd to sprowadzenie wszystkich tych sytuacji do jednej kolumny „pewność: 80%”. Taka liczba miesza jakość źródła, kompletność dowodu, niepewność pomiaru, siłę wnioskowania i prawdopodobieństwo zdarzenia. System redakcyjny musi je rozdzielać, zachowując przy tym prostą warstwę wizualną dla czytelnika.

Reguła podstawowa: oznaczenie przysługuje twierdzeniu wraz z jego warunkami, wersją i evidence. Nie dziedziczy się automatycznie z wiarygodnego źródła ani z sąsiedniego akapitu.

Spis treści#

• Pięć etykiet publikacyjnych
• Etykieta to nie confidence i nie probability
• Atomowe twierdzenie techniczne
• Evidence i provenance
• Hierarchia źródeł bez automatyzmu
• Potwierdzone
• Producent deklaruje
• Źródła publiczne podają
• Szacunek
• Informacja niepotwierdzona
• Pomiar, kalibracja i niepewność
• Obliczenie i wynik modelu
• Zdjęcia, wideo i pomiary geometryczne
• Niezależność potwierdzeń
• Sprzeczne źródła
• Dane platform wojskowych
• Czas, wersja i rewalidacja
• Confidence analityczne
• Prawdopodobieństwo zdarzenia
• Model danych i automatyczne kontrole
• Prezentacja w artykule
• Workflow redakcyjny
• Powiązane tematy
• Przypisy

Pięć etykiet publikacyjnych#

Portal używa pięciu etykiet pochodzenia i stanu dowodu:

Etykiety są rozłączne jako status prezentacyjny jednej wartości w danym wydaniu, ale historia może pokazywać przejście. Liczba początkowo „niepotwierdzona” może stać się „źródła publiczne podają”, potem „producent deklaruje”, a po niezależnym badaniu — „potwierdzona”. Nie nadpisuje się historii decyzji.

„Potwierdzone” jest celowo wymagające. Dwie strony kopiujące ten sam komunikat producenta nie tworzą niezależnego potwierdzenia. Zdjęcie urządzenia potwierdza jego widoczną cechę, lecz nie zasięg radiowy. Test jednego egzemplarza potwierdza wynik tego testu, nie automatycznie limit całej populacji.

Etykieta to nie confidence i nie probability#

Trzy różne pytania wymagają trzech różnych pól:

1. jaki jest status pochodzenia twierdzenia? — pięć etykiet publikacyjnych;
2. jak silna jest podstawa wniosku? — confidence analityczne;
3. jak prawdopodobne jest przyszłe lub nieobserwowane zdarzenie? — likelihood/probability.

ODNI ICD 203 wymaga rozdzielania informacji źródłowej, założeń i ocen oraz wyjaśniania podstaw confidence. Standard ostrzega także przed mieszaniem poziomu confidence z likelihood w tym samym sformułowaniu [1]. Ta zasada jest użyteczna również poza analizą wywiadowczą.

Przykład:

Producent deklaruje endurance do 45 min w konfiguracji bez payloadu. Na podstawie masy wariantu z kamerą i pomiaru zużycia energii szacujemy 31–35 min w bezwietrznym locie poziomym; confidence średnie, ponieważ brak pełnej mapy sprawności śmigło–silnik. Prawdopodobieństwo osiągnięcia co najmniej 30 min w opisanym profilu oceniono jako wysokie po trzech powtórzeniach testu.

W tym zdaniu deklaracja, szacunek, confidence i prawdopodobieństwo mają osobne role. Zastąpienie ich ikoną „85% pewności” usunęłoby najważniejsze informacje.

Atomowe twierdzenie techniczne#

Twierdzenie musi być na tyle małe, aby można je było potwierdzić lub odrzucić jednym zestawem evidence. Rekord powinien mieć postać:

subject + property + value + unit + conditions
+ variant/version + valid time + source/evidence + status

Przykład niepełny:

Zasięg: 200 km.

Przykład kontrolowany:

subject: Platforma X, wariant Block 2
property: producent-declared maximum control-link range
value: 200
unit: km
conditions: LOS, konfiguracja anten niepodana
valid_at: datasheet revision 4, 2025-03
status: producent deklaruje
evidence: dokument ABC-123 rev. 4, tabela 2, wiersz 7

Warunki są częścią wartości. „Prąd 60 A” bez czasu, chłodzenia, temperatury i napięcia nie jest tym samym twierdzeniem co „60 A ciągle przy przepływie 5 m/s i temperaturze otoczenia 25°C”. Rozdzielenie chroni przed łączeniem liczb o pozornie tej samej nazwie.

Twierdzenia złożone trzeba rozbić. Zdanie „platforma ma redundantny system nawigacyjny i jest odporna na utratę GNSS” zawiera co najmniej trzy kwestie: liczbę torów, niezależność ich common causes i zachowanie funkcji po utracie obserwacji. Rysunek dwóch anten może potwierdzić pierwszy fragment, ale nie dwa pozostałe.

Evidence i provenance#

Source to dokument, osoba, dataset, repozytorium, próbka lub obserwacja. Evidence to konkretny fragment albo wynik użyty do podparcia twierdzenia. Provenance opisuje drogę od źródła przez przetworzenia do opublikowanej wartości.

Minimum evidence record:

• unikalny identyfikator;
• typ: dokument, tabela danych, zdjęcie, próbka, pomiar, log, kod, wywiad;
• autor/wydawca/właściciel;
• tytuł, numer, rewizja i data;
• trwały URL lub lokalny identyfikator archiwalny;
• data pozyskania;
• hash zachowanej kopii, jeśli licencja i proces pozwalają;
• lokalizacja: strona, tabela, wiersz, timestamp, commit;
• zakres, warunki i ograniczenia;
• relacja do claim: supports, contradicts, contextualizes;
• transformacje wykonane przez redakcję.

Link do strony głównej producenta jest słabym provenance dla liczby. Czytelnik powinien móc dotrzeć do tabeli lub sekcji, w której wartość występuje. Dla repozytorium wskazuje się commit i ścieżkę, nie tylko branch main. Dla filmu — timestamp i kryteria identyfikacji klatki.

NASA Technical Data Management podkreśla identyfikację i kontrolę danych, integralność, ochronę, dostęp w punkcie użycia oraz metadata umożliwiające wyszukanie [2]. Te zasady stosujemy także do publicznych materiałów: kopia bez daty i wersji nie pozwala zweryfikować, co redakcja rzeczywiście widziała.

Łańcuch provenance powinien być odwracalny. Jeśli publikujemy 2,35 kg, rekord musi wskazać, czy jest to przepisana wartość, średnia z pomiarów, suma BOM czy wynik modelu. Zaokrąglenie, konwersja jednostek, odjęcie tary i korekta kalibracyjna są transformacjami, nie niewidzialnymi detalami.

Hierarchia źródeł bez automatyzmu#

Źródła pierwotne zwykle mają przewagę, bo zmniejszają liczbę pośredników, lecz „pierwotne” nie oznacza „bezstronne” ani „adekwatne do pytania”. Producent jest najlepszym źródłem pinoutu własnego układu, ale deklaracja zasięgu może pochodzić z idealnego scenariusza marketingowego. Niezależne laboratorium może dobrze mierzyć RF, lecz pomylić wariant platformy.

Praktyczna kolejność poszukiwania:

1. released specification, datasheet, standard, oficjalny rysunek i repozytorium;
2. raport testu, certyfikat lub measurement dataset z metodą;
3. dokument instytucji publicznej lub naukowa publikacja techniczna;
4. patent i materiały postępowania zakupowego — przy zachowaniu różnicy między opisem a wdrożeniem;
5. raport branżowy z jawnie opisanymi źródłami;
6. fotografia/wideo z możliwym do ustalenia pochodzeniem;
7. relacja prasowa;
8. anonimowy wpis, agregator lub treść bez provenance.

Ocena źródła obejmuje osobno:

• dostęp do informacji — czy autor mógł bezpośrednio obserwować cechę;
• kompetencję — czy rozumiał przedmiot i metodę;
• motywację oraz bias — jakie miał interesy;
• autentyczność — czy dokument/obraz jest tym, za co się podaje;
• aktualność — czy dotyczy właściwej wersji i czasu;
• precyzję — czy podaje warunki i tolerancje;
• powtarzalność — czy inne osoby mogą odtworzyć wynik;
• spójność — czy nie przeczy sam sobie i innym silnym dowodom.

Nie wylicza się mechanicznej średniej tych pól. Źródło może mieć wysoką kompetencję i dostęp, ale silną motywację marketingową; może być autentyczne, lecz nieaktualne. Ocena ma zachować ten profil.

Potwierdzone#

Status potwierdzone przyznaje się, gdy evidence bezpośrednio odpowiada claim, jest identyfikowalne i przeszło kontrolę adekwatną do ryzyka. Typowe przypadki:

• wymiar zmierzony zwalidowanym systemem pomiarowym na oznaczonym egzemplarzu;
• funkcja potwierdzona testem z procedurą, warunkami i surowym wynikiem;
• zawartość firmware potwierdzona hash artefaktu i odtwarzalnym build/release record;
• pinout potwierdzony released datasheetem właściwego orderable MPN i rewizji, a dla własnej konstrukcji dodatkowo dokumentacją projektu;
• konfiguracja konkretnego egzemplarza potwierdzona genealogią as-built i kontrolą fizyczną.

Status musi określać populację. Pomiar masy 2381,6 g ± 1,2 g potwierdza masę badanego egzemplarza w określonej konfiguracji. Aby opisać populację produkcyjną, potrzebny jest sampling, tolerance specification lub dane EOL wielu sztuk.

Dokument urzędowy może potwierdzać, że urząd zarejestrował określoną wartość albo że kontrakt zawierał dane wymaganie. Nie musi potwierdzać osiągów fizycznego produktu. Trzeba formułować claim zgodnie z tym, co dokument faktycznie dowodzi.

Potwierdzenie jest zakresowe. Test komunikacji na 10 km nie potwierdza maksymalnego zasięgu 50 km; potwierdza utrzymanie łącza w wykonanym teście. Brak awarii w jednej godzinie nie potwierdza MTBF.

Producent deklaruje#

Status producent deklaruje dotyczy danych przekazanych przez organizację projektującą lub oferującą produkt, których portal nie zweryfikował niezależnie. Jest neutralny: nie sugeruje ani prawdziwości, ani fałszu.

Należy zapisać:

• podmiot składający deklarację;
• dokument i rewizję;
• dokładną terminologię producenta;
• warunki lub ich brak;
• wariant i datę;
• czy wartość jest limit, typical, maximum, guaranteed czy marketingowe „up to”.

Nie wolno wzmacniać deklaracji przez parafrazę. Up to 45 min nie staje się „czas lotu wynosi 45 min”. Range 100 km nie wyjaśnia, czy chodzi o control link, ferry range, mission radius czy całkowitą trasę. Jeżeli producent nie podaje definicji, brak ma pozostać widoczny.

Datasheet producenta może zawierać zarówno parametry gwarantowane, jak i typical curves. Dla komponentu elektronicznego status publikacyjny może pozostać „producent deklaruje”, a pole guarantee level określać min/max guaranteed under stated conditions. To precyzyjniejsze niż awansowanie całego dokumentu do „potwierdzone”.

Źródła publiczne podają#

Etykieta źródła publiczne podają służy danym przypisanym do jawnych źródeł, które nie stanowią bezpośredniej deklaracji producenta ani potwierdzenia redakcji. Trzeba wymienić źródła i ich charakter.

Przykłady:

• instytucja państwowa publikuje ocenę wymiarów obcej platformy;
• raport badawczy opisuje odzyskane elementy, ale nie udostępnia pełnych danych pomiarowych;
• media cytują urzędnika lub operatora;
• kilka analiz branżowych podaje ten sam zakres osiągów.

Liczba publikacji nie jest liczbą potwierdzeń. Pięć artykułów może kopiować jedną agencję prasową, a trzy raporty — tę samą anonimową prezentację. System powinien rejestrować root source i zależności cytowania. Dopóki nie znaleziono źródła pierwotnego, fakt kopiowania należy jawnie zaznaczyć.

Sformułowanie powinno zachować atrybucję: „raport X podaje”, „według dokumentu Y”, „dwa niezależne źródła publiczne opisują”. Nie należy usuwać podmiotu i pisać wartości jako bezosobowego faktu.

Szacunek#

Status szacunek wymaga metody, danych wejściowych i zakresu niepewności. Sama intuicja eksperta bez zapisu założeń jest hipotezą, nie udokumentowanym szacunkiem.

Rekord szacunku powinien zawierać:

• pytanie i measurand/output;
• wejścia z własnymi statusami evidence;
• równanie, model lub algorytm;
• założenia i uproszczenia;
• zakres ważności modelu;
• sensitivity na główne wejścia;
• wynik jako przedział lub rozkład, nie fałszywie dokładną liczbę;
• walidację na znanym przypadku, jeśli możliwa;
• autora, datę i wersję obliczenia.

Przykład czasu lotu:

usable_energy = nominal_voltage × capacity × usable_fraction
average_power = measured_hover_power + avionics_power + payload_power
estimated_time = usable_energy / average_power

Wynik 31,742 min jest nieuzasadniony, jeśli średnia moc ma niepewność ±15%, usable fraction jest przyjęta arbitralnie, a temperatura nieznana. Uczciwszy przedział 27–35 min pokazuje ograniczenia modelu.

Jeżeli wejście jest niepotwierdzone, wynik nie może stać się potwierdzony tylko dlatego, że użyto poprawnego równania. Provenance szacunku zachowuje najsłabsze istotne założenia. Można jednak mieć wysokie confidence, że wynik modelu dla przyjętych wejść obliczono poprawnie, i niskie confidence, że wejścia opisują rzeczywistą platformę.

Informacja niepotwierdzona#

Etykieta informacja niepotwierdzona jest kontrolowanym ostrzeżeniem, nie koszem na plotki. Twierdzenie publikuje się tylko wtedy, gdy jest istotne dla zrozumienia sporu, kieruje dalszą weryfikacją albo krąży na tyle szeroko, że warto wyjaśnić brak dowodów.

Rekord powinien odpowiadać:

• kto i gdzie wysunął twierdzenie;
• czego dokładnie dotyczy;
• czego brakuje do weryfikacji;
• czy istnieje evidence przeciwne;
• jakie obserwacje mogłyby podnieść lub obniżyć confidence;
• kiedy status zostanie ponownie sprawdzony.

Nie należy publikować anonimowej sensacji tylko dlatego, że etykieta ogranicza odpowiedzialność. Powtarzanie zwiększa zasięg dezinformacji. Redakcja najpierw ocenia wartość informacyjną, ryzyko szkody i możliwość uczciwego kontekstu.

„Informacja wymaga dodatkowej weryfikacji” jest właściwe także dla pola pozostawionego w katalogu, gdy wiadomo, że parametr istnieje, ale nie znaleziono wartości. Nie wolno wstawiać zera, średniej klasowej ani liczby z podobnego wariantu.

Pomiar, kalibracja i niepewność#

Wynik pomiaru to wartość wraz z niepewnością i warunkami. NIST definiuje metrological traceability jako właściwość wyniku związanego z odniesieniem przez udokumentowany, nieprzerwany łańcuch kalibracji, z których każde wnosi niepewność [3]. Sam napis „miernik kalibrowany” nie nadaje traceability wszystkim wynikom.

Minimum rekordu pomiarowego:

• jednoznaczny measurand;
• identyfikacja próbki/egzemplarza i konfiguracji;
• metoda i setup;
• instrument, zakres, resolution i status kalibracji;
• warunki środowiskowe;
• raw observations i reguły odrzucania;
• corrections;
• wynik, jednostka i expanded/standard uncertainty;
• coverage factor lub confidence interval;
• osoba, czas i software analityczne;
• kryterium decyzji, jeśli wynik służy pass/fail.

Traceability nie oznacza automatycznie fitness for purpose. NIST podkreśla, że niepewność może być zbyt duża dla konkretnej decyzji, nawet gdy łańcuch odniesienia jest poprawny [3]. Suwmiarka z aktualną kalibracją nie jest właściwym narzędziem do oceny mikrometrowej współosiowości.

W publikacji rozdzielamy:

• resolution wskazania;
• repeatability w serii;
• systematic correction/bias;
• measurement uncertainty;
• tolerance/specification produktu;
• guard band/decision rule.

Pięć odczytów zgodnych do trzeciego miejsca po przecinku nie dowodzi dokładności do tego miejsca. Wspólny bias instrumentu nie ujawnia się jako scatter.

Obliczenie i wynik modelu#

Wynik obliczenia deterministycznego może być dokładny względem wejść, ale nadal niepewny względem rzeczywistości. Dla sumy mas BOM błąd może pochodzić z mas katalogowych, brakujących klejów, tolerancji części i zaokrągleń ilości.

Każde obliczenie powinno przechowywać:

• wersję wzoru/kodu;
• jednostki i conversions;
• input IDs, nie ręcznie przepisane liczby;
• reguły rounding;
• output przed i po zaokrągleniu;
• testy na znanych przypadkach;
• zakres stosowalności;
• uncertainty propagation albo sensitivity.

Należy rozróżnić:

• derived value — bezpośredni wynik definicji lub prostego równania;
• simulation result — output modelu fizycznego/numerycznego;
• estimate — wartość wnioskowana przy brakach danych;
• prediction — ocena przyszłego zachowania;
• measurement — wynik porównania z odniesieniem.

Model CFD może być bardzo szczegółowy, ale bez mesh convergence, boundary conditions i validation pozostaje wynikiem modelu. Wysoka liczba elementów siatki nie jest etykietą pewności.

Zdjęcia, wideo i pomiary geometryczne#

Obraz jest evidence tylko dla cech, które można z niego wiarygodnie odczytać. Najpierw ocenia się provenance: oryginalne źródło, czas, miejsce, brak istotnej edycji i identyfikację wariantu. Kompresja, perspektywa i montaż mogą usuwać szczegóły.

Na zdjęciu można często potwierdzić:

• obecność widocznego elementu;
• ogólny układ aerodynamiczny;
• liczbę silników lub powierzchni sterowych;
• względne położenie złączy i anten;
• marking, jeśli jest czytelny i autentyczny.

Nie można bezpośrednio potwierdzić:

• materiału tylko z koloru;
• wewnętrznego układu elektroniki;
• prędkości, zasięgu i odporności na zakłócenia;
• aktywności sensora pod osłoną;
• dokładnego wymiaru bez skali i modelu geometrii.

Photogrammetric estimate wymaga znanego wymiaru referencyjnego, modelu kamery/perspektywy, punktów pomiarowych i zakresu błędu. Dwie osie obiektu w różnych głębokościach nie mogą używać jednego prostego pixel scale. Wynik opisujemy jako szacunek, nawet jeśli piksele zmierzono dokładnie.

Wideo z testu pokazuje konkretny przebieg. Bez informacji o montażu, masie, wietrze, telemetrii i cięciach nie potwierdza osiągów całej klasy. Timestampy i pełny materiał źródłowy są ważniejsze niż atrakcyjny fragment.

Niezależność potwierdzeń#

Źródła są niezależne, jeśli nie wywodzą danych z tego samego root source i mają niezależny dostęp lub metodę. Różne domeny, języki albo nazwiska nie gwarantują niezależności.

Typowe pozorne potwierdzenia:

• komunikat producenta przedrukowany przez media;
• artykuły cytujące tę samą agencję;
• raporty używające tej samej fotografii;
• datasheet dystrybutora będący kopią PDF producenta;
• kilka kont publikujących ten sam klip;
• baza danych powielająca wcześniejszą bazę bez atrybucji.

Graf cytowań powinien prowadzić do root evidence. Gdy ścieżka jest nieznana, źródła oznacza się jako possibly dependent, nie liczy jako oddzielne potwierdzenia.

Niezależne metody są szczególnie wartościowe: masa z ważenia i suma z BOM; wymiar z rysunku oraz photogrammetry; firmware version z telemetrii i hash odczytanego obrazu. Zgodność zmniejsza ryzyko wspólnego błędu. Rozbieżność ujawnia problem, którego „większość stron” mogłaby nie wykryć.

Sprzeczne źródła#

Konfliktu nie rozwiązuje się przez wybranie liczby środkowej. Najpierw sprawdza się, czy źródła opisują ten sam:

• wariant i rewizję;
• rodzaj parametru;
• układ jednostek;
• stan/warunki testu;
• czas;
• definicję, np. range kontra radius;
• poziom agregacji, np. empty mass kontra MTOW.

Jeżeli konflikt pozostaje, artykuł powinien pokazać wartości równolegle:

Redakcja może wskazać preferowaną interpretację, ale musi podać argument: lepsza identyfikacja wariantu, bezpośredni pomiar, aktualniejszy dokument. Pozostałe dane nie znikają z historii.

Conflict record zawiera claims, evidence, hipotezy wyjaśniające, stan rozstrzygnięcia oraz akcję potrzebną do zamknięcia. Unknown jest poprawnym wynikiem.

Dane platform wojskowych#

Profile wojskowych UAV łączą dane producentów, dokumenty zakupowe, komunikaty stron konfliktu, zdjęcia odzyskanych elementów, raporty instytucji i szacunki analityczne. Motywacje i ograniczenia dostępu są silniejsze niż w zwykłym katalogu części.

Każdy parametr powinien mieć osobny status. Przykładowa karta:

manufacturer: producent deklaruje
country of origin: potwierdzone dokumentami i markings
length: potwierdzone dla badanego egzemplarza; wariant niepewny
maximum range: producent deklaruje
operational radius: źródła publiczne podają, definicja niejednolita
warhead mass: informacja niepotwierdzona / poza zakresem instruktażowym
navigation architecture: szacunek na podstawie odzyskanych modułów

Strona konfliktu może poprawnie udokumentować zdobyty egzemplarz, a jednocześnie selektywnie przedstawiać jego znaczenie. Oceniamy claim, nie flagę. Materiał wizualny wymaga geolokalizacji/chronolokacji tylko wtedy, gdy miejsce i czas są częścią twierdzenia.

Nie wolno łączyć części z różnych wariantów w jeden pozornie kompletny diagram. Jeśli flight controller znaleziono w egzemplarzu A, a modem w B, architektura zbiorcza jest hipotezą dotyczącą rodziny, nie potwierdzonym opisem jednego statku.

Dane ofensywne są dodatkowo ograniczone zasadami bezpieczeństwa portalu. Etykieta ALIGNMENT oznacza celowe pominięcie wykonawczej instrukcji, a nie niską pewność faktu. Pole safety scope pozostaje niezależne od evidence status.

Czas, wersja i rewalidacja#

Twierdzenie może być prawdziwe dla starej rewizji i błędne dla bieżącej. Każdy rekord ma:

• observed_at lub valid_from/valid_to;
• wersję/variant/effectivity;
• retrieved_at dla źródła;
• verified_at dla decyzji redakcyjnej;
• review_due_at zależne od zmienności;
• powód wygaśnięcia albo superseding claim.

Tempo rewalidacji nie jest jednakowe. Prawa aerodynamiczne starzeją się wolno; ceny, status EOL, firmware i przepisy — szybko. Parametr datasheetu sprawdza się po PCN/nowej rewizji. Dane platformy wojskowej po pojawieniu się nowego wariantu lub raportu z badań.

Automatyczny checker może wykrywać niedostępne URL, zmianę hash dokumentu, nowy release repozytorium i przekroczony review due. Nie może sam uznać, że treść merytoryczna pozostała prawdziwa. Zmiana PDF pod tym samym URL wymaga diff i review.

Historyczne claims zachowuje się jako superseded, aby artykuł mógł wyjaśnić ewolucję wiedzy. Silent overwrite niszczy audytowalność.

Confidence analityczne#

Confidence opisuje siłę podstawy analitycznego wniosku, nie procent prawdopodobieństwa. W portalu stosujemy trzy poziomy wraz z obowiązkowym uzasadnieniem:

Samo słowo bez rationale jest niewystarczające. Uzasadnienie powinno wskazać strengths, gaps, assumptions, contrary evidence i wskaźniki mogące zmienić ocenę. ICD 203 wiąże confidence z jakością i ilością materiału, logiką oraz rozumieniem tematu [1].

Przykład:

Oceniamy z średnim confidence, że moduł pełni funkcję redundantnego odbiornika GNSS: oznaczenia układu i tor RF są zgodne, ale brak firmware oraz ciągłości połączeń do autopilota. Odczyt konfiguracji lub schematic podniósłby confidence; wykazanie, że tor kończy się na rejestratorze, obniżyłoby je.

Confidence nie przechodzi automatycznie na każdy szczegół wniosku. Można z wysokim confidence zidentyfikować rodzinę MCU, lecz z niskim — jego firmware role.

Prawdopodobieństwo zdarzenia#

Probability dotyczy zdarzenia losowego albo niepewnego stanu: szansy awarii w profilu, osiągnięcia czasu lotu, wystąpienia opadu. Nie jest oceną jakości dokumentu.

Jeśli używamy terminów słownych, publikujemy przypisane zakresy albo podajemy liczbę z modelem. Nie mieszamy w jednym zdaniu „wysokie confidence” i „bardzo prawdopodobne” tak, jakby były synonimami.

Źródła probability mogą być różne:

• częstość z danych eksploatacyjnych;
• reliability model;
• Monte Carlo z rozkładami wejść;
• ekspercka ocena przy braku danych;
• posterior po obserwacjach.

Każdy model wymaga population, exposure i czasu. 1% awarii bez liczby lotów, godzin, warunków i definicji awarii jest nieużyteczne. Przy zerze awarii w małej próbce ryzyko nie wynosi zero.

Model danych i automatyczne kontrole#

Minimalny model:

claim(claim_id, subject_id, property_id, value, unit,
      conditions, variant, valid_from, valid_to,
      publication_status, confidence, rationale,
      verified_at, review_due_at)

evidence(evidence_id, source_id, evidence_type, locator,
         acquired_at, hash, scope, limitations)

claim_evidence(claim_id, evidence_id, relation,
               transformation_id, reviewer_id)

transformation(transformation_id, method, code_version,
               inputs, assumptions, output, uncertainty)

publication_status jest jedną z pięciu etykiet. confidence może być puste dla prostego cytatu, a jest wymagane dla złożonego wniosku. relation przyjmuje supports, contradicts albo context. Źródło ma własną ocenę wymiarową, ale nie jeden magiczny score.

Linter powinien sprawdzać:

• wartość liczbowa ma jednostkę i warunki;
• status „potwierdzone” ma bezpośrednie evidence i review;
• status „producent deklaruje” wskazuje producenta i dokument;
• „źródła publiczne podają” zachowuje atrybucję;
• „szacunek” ma transformation, inputs i assumptions;
• „niepotwierdzone” ma rationale oraz review date;
• confidence ma uzasadnienie;
• claim nie cytuje źródła późniejszego niż data publikacji bez późniejszej rewizji;
• source revision/hash nie zmienił się bez review;
• wartości sprzeczne mają conflict record;
• wygasły claim nie jest prezentowany jako bieżący;
• konwersja jednostek zachowuje precision i provenance.

Automatyczna zgodność nie dowodzi prawdziwości. Gwarantuje, że twierdzenie ma kompletny ślad i zostało sklasyfikowane według reguł.

Prezentacja w artykule#

Kolor nie może być jedynym nośnikiem statusu. Etykieta ma tekst, ikonę opcjonalną i dostępny opis. W tabeli wartość oraz status pozostają w osobnych kolumnach.

Przykład:

Tooltip może skracać wyjaśnienie, ale pełny status musi być dostępny bez hover i dla klawiatury. W druku/PDF znaczenie nie może zniknąć po usunięciu koloru.

Etykieta przy całej tabeli jest dopuszczalna tylko wtedy, gdy wszystkie komórki mają to samo provenance i zakres. W innym przypadku status umieszcza się per row albo per cell.

Workflow redakcyjny#

Proces dla istotnego claim:

1. zapisz dokładne twierdzenie bez wygładzania;
2. określ subject, property, variant, czas i warunki;
3. pozyskaj źródło pierwotne lub opisz, dlaczego go brak;
4. zapisz evidence locator oraz kopię/hash zgodnie z licencją;
5. oceń dostęp, kompetencję, bias, autentyczność i aktualność;
6. rozpoznaj root source oraz zależności cytowania;
7. oddziel dane, założenia i wniosek;
8. przypisz status publikacyjny;
9. dla wniosku przypisz confidence z rationale;
10. sprawdź contrary evidence i alternatywne wyjaśnienia;
11. wykonaj niezależny review proporcjonalny do ryzyka;
12. ustaw verified_at i review_due_at.

NASA Requirements Verification Matrix wiąże każde wymaganie z jednoznacznym źródłem i metodą weryfikacji [4]. Analogiczna claim–evidence matrix pozwala sprawdzić, czy każde ważne zdanie artykułu ma adekwatną podstawę, a nie tylko długą bibliografię na końcu.

Bibliografia artykułu nie jest miarą jakości sama w sobie. Dziesięć źródeł w sekcji „Przypisy” nie pomaga, jeśli nie wiadomo, które wspiera dany parametr. Najważniejsze jest lokalne, jednoznaczne powiązanie.

Krytyczne poprawki powinny zachowywać change record: stara wartość, nowa wartość, nowe evidence, powód i reviewer. W ten sposób czytelnik widzi rozwój stanu wiedzy, a redakcja może znaleźć systematyczne błędy metody.

Powiązane tematy#

• Jak czytać datasheet części UAV — gwarancje, typowe wartości, warunki i rewizje dokumentów.
• Jak prowadzić BOM UAV — status danych części, MPN, kwalifikacje i effectivity.
• Metrologia dla konstruktora UAV — niepewność pomiaru, kalibracja i reguły decyzji.
• Identyfikowalność produkcji UAV — provenance konkretnej konfiguracji as-built.
• Shahed-136 — analiza konstrukcji — rozdzielenie danych potwierdzonych, publicznych i szacowanych.
• Platformy wojskowe — klasy — parametry i ograniczenia porównywania klas.

Przypisy#

1. ODNI ICD 203: Analytic Standards — jakość źródeł, niepewność, confidence, likelihood oraz rozdzielenie informacji, założeń i ocen.
2. NASA Systems Engineering Handbook: Technical Data Management — identyfikacja, metadata, integralność, ochrona, dostęp i utrzymanie danych technicznych.
3. NIST: Metrological Traceability — Frequently Asked Questions and Policy — traceability wyniku, łańcuch kalibracji, uncertainty i fitness for purpose.
4. NASA Systems Engineering Handbook: Requirements Verification Matrix — wiązanie jednoznacznego wymagania ze źródłem i metodą weryfikacji.
5. NASA Systems Engineering Handbook: Product Verification — obiektywne evidence, verification i validation.
6. NASA Systems Engineering Handbook: Configuration Management — baseline, kontrola zmian i historyczna zgodność produktu z informacją.

Powiązane tematy

Jak czytać datasheet części UAV — od symbolu do wymagania projektowegoMetodyka czytania datasheetów części UAV: identyfikacja producenta, dokumentu, rewizji, orderable MPN, package i grade; rozdzielenie stress ratings od warunków działania, parametrów gwarantowanych i typowych; znaczenie footnotes, test conditions, bins i temperature range. Artykuł obejmuje derating napięcia, prądu i temperatury, SOA, junction/case/ambient oraz ograniczenia θJA, timing i waveform definitions, noise density, bandwidth i ODR sensorów, tolerancje baterii/silników/ESC, mechanical drawing, land pattern, MSL, reflow, software/errata, PCN/EOL, konflikty dokumentów, evidence matrix, kalkulację worst-case oraz przekład każdej istotnej wartości na requirement, verification i pole katalogu.Jak prowadzić BOM UAV — konfiguracja sprzętu, software i wariantówPraktyczny model BOM dla UAV: rozdzielenie struktury projektowej EBOM, produkcyjnej MBOM, programowej SBOM, serwisowej i konfiguracji as-built; wewnętrzne part numbers, MPN, SKU dostawcy, serie i partie; assemblies, phantom items, materiały masowe, ilości i jednostki. Artykuł obejmuje parametryczne warianty produktu, option codes i effectivity, alternates/approved manufacturer list, rygor kwalifikowania zamienników dla sensorów, napędu i elektroniki, powiązanie hardware–firmware–parametry, rewizje i change control, PCN/EOL/DMSMS, sourcing bez mieszania z definicją części, reguły walidacji drzewa, release workflow, BOM diff, minimalny model relacyjny oraz połączenie BOM z produkcyjną genealogią konkretnego egzemplarza.Metrologia dla konstruktora UAV — pomiar, niepewność i decyzjaPraktyczna metrologia konstrukcji UAV od decyzji i definicji measurandu do audytowalnego wyniku. Artykuł rozdziela resolution, repeatability, trueness/accuracy, błąd i niepewność; opisuje kalibrację, adjustment, verification i traceability; budowę modelu pomiaru, składniki Type A/Type B, sensitivity coefficients, korelacje, combined i expanded uncertainty. Obejmuje MSA/Gage R&R, bias, linearity, hysteresis, stability i drift, dobór przyrządu do tolerancji, guard bands oraz false accept/reject, out-of-tolerance impact review, kontrolę software i danych, a także tory masy i środka ciężkości, geometrii, ciągu, momentu, RPM, elektryki, temperatury, drgań i czasu z przykładami budżetu niepewności.Identyfikowalność produkcji UAV — od partii materiału do konkretnej sztukiPraktyczny model identyfikowalności UAV oparty na relacji obiekt–zdarzenie–dane: serializacja wyrobu, partie materiałów i komponentów, agregacja oraz transformacja, CTE/KDE, Who/What/Where/When/Why, genealogia wejść, procesu i wyjść, rozdzielenie as-designed, as-planned, as-built i as-maintained. Artykuł obejmuje BOM i rewizje, narzędzia oraz kalibracje, firmware/parametry/klucze, surowe wyniki kontroli, NCR, deviation, rework i repair, chain of custody, containment oraz recall, retencję, integralność i migrację danych, minimalny schemat relacyjny, kodowanie Data Matrix/RFID, offline capture, audyt odtworzeniowy i metryki czasu identyfikacji populacji ryzyka.Shahed‑136 / Geran‑2 — analiza konstrukcji i wariantówŹródłowa analiza rodziny Shahed‑136/Geran‑2 z jasno wskazanym baseline’em dwóch rosyjskich egzemplarzy z lipca 2023 r.: aerodynamika, kompozyty, MD‑550, bloki B‑101/B‑105/B‑103, PNT, zasilanie, produkcja oraz porównanie rewizji irańskich, rosyjskich i odrzutowych.Klasy wojskowych UAVTechniczna taksonomia wojskowych UAS: formalne klasy NATO I–III i amerykańskie grupy 1–5 bez mylenia podobnych numerów, a następnie niezależne osie masy, pułapu, misji, aerodynamiki, startu, łączności, autonomii, recoverability, przeżywalności, logistyki i segmentu naziemnego. Zawiera macierz rzeczywistych platform, przypadki graniczne oraz model danych i procedurę klasyfikowania nowych wariantów.

Źródła z centralnego rejestru

1. ODNI ICD 203: Analytic Standards [oficjalny standard rozdzielania danych źródłowych, założeń, ocen, likelihood i confidence oraz opisu jakości źródeł]
2. NIST: Metrological Traceability — FAQ and policy [oficjalne wyjaśnienie traceability, kalibracji i niepewności]
3. NASA Systems Engineering Handbook: Technical Data Management [oficjalna metodyka identyfikacji, integralności, retencji, dostępu i aktualizacji danych technicznych]
4. NASA Systems Engineering Handbook: Requirements Verification Matrix [oficjalny przykład wiązania jednoznacznych wymagań ze źródłem i metodą weryfikacji]
5. NASA Systems Engineering Handbook: Product Verification [oficjalna metodyka rozróżniająca verification, qualification, acceptance, certification oraz end-to-end testing]
6. NASA Systems Engineering Handbook: Configuration Management [oficjalna metodyka identyfikacji konfiguracji, baseline, change control, status accounting i audytów konfiguracji]
7. NASA Systems Engineering Handbook, Rev. 2 [oficjalny podręcznik inżynierii systemów i kontroli interfejsów]