k0nsult.cloud / Common-Source-of-Truth / common-source-of-truth

Prawda i dowody

K0-CST (Common Source of Truth) — jeden kanon faktów dla całego portalu K0NSULT. Każde twierdzenie musi mieć przypisany dowód. Brak dowodu nie jest faktem — jest luką.

claim ≤ proof — nie twierdzimy więcej niż możemy wykazać.

Siła każdego twierdzenia nie może przekraczać siły dowodu, który za nim stoi. Jeśli dowód obejmuje wycinek, twierdzenie ogranicza się do tego wycinka. Claim bez dowodu trafia automatycznie do statusu GAP lub DRAFT — nigdy do FACT.

1. Osiem statusów prawdy

Każde twierdzenie w K0-CST ma dokładnie jeden z poniższych statusów. Definicje nie mylą faktów z narracją — status odzwierciedla siłę dowodu, nie intencję autora.

FACT

Zweryfikowany fakt — twierdzenie potwierdzone źródłem, które można wskazać i niezależnie sprawdzić.

OFFICIAL

Stanowisko organu — treść pochodzi z dokumentu lub odpowiedzi organu regulacyjnego, sądowego lub administracyjnego.

TECHNICAL

Ustalenie techniczne — wynik pomiaru, testu lub audytu technicznego przeprowadzonego przez wskazanego aktora.

GAP

Brak dowodu = luka, NIE fakt — twierdzenie bez wystarczającego źródła; czeka na dowód zamiast być prezentowane jako fakt.

DISPUTED

Sporny — istnieją co najmniej dwa sprzeczne dowody lub strony kwestionują twierdzenie; spór jest udokumentowany.

SIMULATION

Dane symulacyjne, nie realne — twierdzenie pochodzi z modelu lub scenariusza; nie odzwierciedla stanu faktycznego.

DRAFT

Roboczy — twierdzenie w przygotowaniu, dowód niekompletny; nie publikowane jako ustalenie końcowe.

ARCHIVED

Zarchiwizowany — twierdzenie historyczne, dowód zdezaktualizowany lub wycofany; zachowane wyłącznie dla audytu.

2. Zasada claim ≤ proof

claim ≤ proof: nie twierdzimy więcej, niż możemy wykazać. Zakres twierdzenia musi mieścić się w zakresie dowodu — nie uogólniamy ponad to, co potwierdzone. Każde przekroczenie tej granicy wymaga jawnej korekty statusu lub nowego dowodu.

Zasada obowiązuje wszystkich aktorów portalu: operatora, agentów AI, partnerów i organy. Automatyczne reguły walidacji wymuszają jej stosowanie na poziomie modelu danych.

3. Model danych: Claim

Każde twierdzenie jest obiektem z pełnym zestawem pól audytowalnych.

Pole	Typ	Opis
claim_id	UUID	Unikalny identyfikator twierdzenia; niezmienny przez cały cykl życia.
statement	string	Precyzyjna treść twierdzenia w języku naturalnym.
source_ids[]	UUID[]	Tablica identyfikatorów źródeł powiązanych z twierdzeniem.
evidence_ids[]	UUID[]	Tablica identyfikatorów artefaktów dowodowych (dokumenty, logi, API response).
status	enum	Jeden z ośmiu statusów: FACT · OFFICIAL · TECHNICAL · GAP · DISPUTED · SIMULATION · DRAFT · ARCHIVED.
owner	actor_id	Aktor odpowiedzialny za utrzymanie twierdzenia i jego aktualizację.
created_at	ISO 8601	Data i czas pierwszego wprowadzenia twierdzenia do systemu.
updated_at	ISO 8601	Data i czas ostatniej modyfikacji; każda zmiana tworzy nową wersję.
version	semver	Numer wersji twierdzenia; inkrementowany przy każdej zmianie treści lub statusu.
visibility	enum	Zakres widoczności: `public` / `internal` / `restricted`.
appeal_path	URL / ref	Ścieżka odwołania — wskazanie trybu i kanału kwestionowania twierdzenia przez każdą stronę.

Reguła automatyczna: claim bez wypełnionych pól source_ids[] lub evidence_ids[] otrzymuje status GAP lub DRAFT — nigdy FACT. Walidacja blokuje zapis sprzecznego stanu na poziomie API.

4. Evidence Graph

Każde twierdzenie osadzone jest w grafie zależności dowodowych. Graf pozwala śledzić pełną ścieżkę od twierdzenia do aktora i działania naprawczego.

claim → source → evidence → actor → damage → owner → action

Relacje są kierunkowe i wersjonowane. Każda krawędź grafu zawiera datę i aktora odpowiedzialnego za połączenie.

claim — twierdzenie w K0-CST
source — dokument, odpowiedź organu, artefakt, API endpoint
evidence — weryfikowalny artefakt potwierdzający źródło
actor — podmiot, do którego twierdzenie się odnosi
damage — udokumentowany skutek (jeśli dotyczy)
owner — aktor odpowiedzialny za twierdzenie po stronie K0NSULT
action — działanie naprawcze lub regulacyjne powiązane z twierdzeniem

Eksport grafu: JSON CSV PDF (P1)

5. Proces dowodowy

Twierdzenie

Formułujemy precyzyjne twierdzenie — co dokładnie ma być wykazane, kto jest aktorem i jaki jest zakres.

Źródło

Przypisujemy dowód: dokument, odpowiedź organu, log, artefakt techniczny lub wpis API. Brak źródła = automatyczny status GAP.

Status

Nadajemy jeden z ośmiu statusów zgodnie z zasadą claim ≤ proof. Status odzwierciedla siłę dowodu, nie intencję.

Wersjonowanie

Twierdzenie otrzymuje wersję i znacznik czasu. Każda zmiana treści lub statusu = nowa wersja, nie cicha edycja historii.

6. Ścieżka odwołania (appeal path)

Każdy wpis w K0-CST zawiera pole appeal_path — jawne wskazanie trybu i kanału, przez który każda strona (operator, podmiot, organ, użytkownik) może zakwestionować twierdzenie.

Zasada: kwestionowanie twierdzenia nie powoduje jego usunięcia — powoduje zmianę statusu na DISPUTED i otwarcie nowego wątku dowodowego. Obie wersje pozostają widoczne w historii wersji.

Typ aktora	Tryb odwołania	Kanał
Podmiot danych / osoba fizyczna	Zgłoszenie RODO / art. 77 RODO	/Common-Source-of-Truth/report
Przedsiębiorca / organizacja	Zgłoszenie merytoryczne z dowodem	/Common-Source-of-Truth/report
Organ regulacyjny	Nakaz lub decyzja administracyjna	Kanał formalny organu + /Common-Source-of-Truth/report
Operator wewnętrzny	Edycja z obowiązkowym komentarzem zmiany	API / panel operatora (restricted)

Po przyjęciu odwołania: twierdzenie otrzymuje status DISPUTED, appeal_path zostaje uzupełniony o numer sprawy, a owner jest zobowiązany do odpowiedzi w ciągu 14 dni lub zmiany statusu na GAP / ARCHIVED.

Zastrzeżenie. Materiał ma charakter informacyjno-badawczy. not a certification · not a notified body · not a legal conclusion. Statusy i wersje odzwierciedlają stan wiedzy na dzień publikacji i podlegają aktualizacji.