K0NSULT // ai-truth/ipIII
k0nsult.cloud / ai-truth / ipIII / orchestrator / truth-engine

K0-TRUTH — Common Source of Truth

Silnik prawdy orchestratora (§4.3). Jedno miejsce, w którym każde twierdzenie systemu — incydent, dowód, claim, decyzja — nosi jawny status prawdy i jest weryfikowalne. To formalizacja doktryny claim ≤ proof w 13 statusach i 6 twardych regułach.

Specyfikacja docelowa (dev-doc). Status: ROADMAP — nie zaimplementowane produkcyjnie. Zgodnie z regułą §16: bez kodu + testu + endpointu = nie LIVE. Ta strona opisuje architekturę docelową silnika K0-TRUTH. Co JUŻ istnieje realnie oznaczono LIVE z odnośnikiem; reszta to ROADMAP.
Doktryna claim ≤ proof jest LIVE (opublikowana, obowiązuje). Silnik jej egzekwowania (walidatory, gate'y, audit-log) jest ROADMAP. System nie wykonuje nieautoryzowanych testów, eksploatacji ani hack-backu poza pisemnym RoE. Zero payloadów.
Claim ≤ Proof. Żadne twierdzenie nie przekracza swojego dowodu.

K0-TRUTH to warstwa, która nadaje każdemu obiektowi w systemie jawny status prawdy i pilnuje, by przejścia między statusami wymagały dowodu. Nie ma „faktu na słowo": jest fakt z pokryciem albo luka (GAP).

ŚCIEŻKA: CLAIMSOURCE?EVIDENCEWERYFIKACJASTATUSCONFIRMED / GAP

13 statusów prawdy

Każdy obiekt (claim, incydent, dowód, decyzja) nosi dokładnie jeden status prawdy. Status jest jawny w UI i w API — nigdy dorozumiany.

#StatusZnaczenie
1FACTFakt zweryfikowany, potwierdzony niezależnym dowodem materialnym. Najwyższy poziom pewności.
2TECHNICALUstalenie techniczne — log, hash, IoC, wynik skanu, dane telemetryczne. Powtarzalne, mierzalne.
3OFFICIALKomunikat organu / źródła oficjalnego (CERT, KNF, CSIRT, dostawca). Autorytatywne, ale nie własny dowód.
4LEGALUstalenie prawne — kwalifikacja wg przepisu (AI Act, NIS2, KSC, RODO). Interpretacja normy, nie faktu.
5CLAIMTwierdzenie zgłoszone, jeszcze nie zweryfikowane. Wymaga source lub degraduje do GAP.
6HYPOTHESISHipoteza robocza analityka. Kierunek dochodzenia, nie ustalenie. Nie może zamknąć incydentu.
7GAPLuka dowodowa — brak pokrycia dla twierdzenia. Jawna, policzalna, blokuje awans do FACT/CONFIRMED.
8DISPUTEDSporne — istnieją sprzeczne dowody lub źródła. Wymaga rozstrzygnięcia z ownerem.
9SIMULATIONDane ćwiczebne / demonstracyjne. NIE realny incydent. Odseparowane od danych operacyjnych.
10ROADMAPFunkcja / komponent planowany, nie zaimplementowany. NIE funkcja produkcyjna (reguła §16).
11INTERNALUstalenie wewnętrzne, nie do publikacji zewnętrznej. Widoczne tylko dla ról uprawnionych.
12RETRACTEDWycofane — twierdzenie odwołane po weryfikacji jako błędne. Zachowane w audit-logu, oznaczone.
13SUPERSEDEDZastąpione — nieaktualne, zastąpione nowszym ustaleniem. Historyczne, z odnośnikiem do następcy.

Awans wymaga dowodu

Przejście CLAIM → FACT / CONFIRMED jest niemożliwe bez wpisu w Evidence Layer. Silnik blokuje, nie prosi.

Degradacja jest automatyczna

CLAIM bez source po terminie weryfikacji spada do GAP. Luka staje się widoczna i policzalna, nie znika.

Separacja SIMULATION

Obiekty SIMULATION nigdy nie mieszają się z operacyjnymi. Osobna przestrzeń, osobne liczniki, jawna etykieta.

6 reguł twardych

Reguły są egzekwowane maszynowo (docelowo), nie zostawione dobrej woli operatora. To one czynią z doktryny silnik.

R1 · Nie zamykaj bez dowodu. Incydent nie może przejść w stan zamknięty bez dowodu naprawy (remediation evidence). Zamknięcie „na słowo" jest zablokowane.
R2 · Nie CONFIRMED bez evidence. Status CONFIRMED / FACT wymaga co najmniej jednego zweryfikowanego wpisu dowodowego. Bez niego maksymalny status to CLAIM.
R3 · SIMULATION ≠ realny incydent. Dane ćwiczebne nigdy nie zasilają metryk operacyjnych, alertów do organów ani KPI produkcyjnych. Trwała separacja przestrzeni.
R4 · ROADMAP ≠ funkcja produkcyjna. Komponent oznaczony ROADMAP nie może być prezentowany jako działający. Reguła §16: bez kodu + testu + endpointu = nie LIVE.
R5 · Każdy claim ma source albo GAP. Nie istnieje twierdzenie „w zawieszeniu": albo wskazuje źródło/dowód, albo jest jawnie oznaczone jako luka (GAP). Trzeciej opcji nie ma.
R6 · Każda decyzja krytyczna ma ownera + audit event. Zmiana statusu P0/P1, zamknięcie, wycofanie — każda niesie identyfikator odpowiedzialnego i niezmienny wpis w audit-logu.

Doktryna → silnik: co jest LIVE, a co ROADMAP

WarstwaElementStatus
DoktrynaZasada claim ≤ proof (opublikowana, obowiązuje)LIVE → doktryna
Doktryna13 statusów prawdy jako słownik pojęćLIVE (zdefiniowane)
Read-pathAPI tylko-do-odczytu /api/ip3/* (ekspozycja statusów)LIVE → API
KontrolaSmoke test read-path (pokrycie endpointów)LIVE
AuthPoC szkieletu autoryzacji (auth-skeleton)LIVE (PoC)
SilnikWalidatory awansu/degradacji statusu (R1–R2, R5)ROADMAP
SilnikGate zamknięcia z dowodem naprawy (R1)ROADMAP
SilnikSeparacja przestrzeni SIMULATION/operacyjnej (R3)ROADMAP
SilnikNiezmienny audit-log ownera decyzji (R6)ROADMAP
SilnikWrite-path (zapis statusów, mutacje) z autoryzacjąROADMAP
13
Statusy prawdy
słownik jawny
6
Reguły twarde
docelowo maszynowe
5
Elementy LIVE
doktryna + read-path + smoke + PoC
§16
Reguła uczciwości
bez kodu+testu+endpointu = nie LIVE

Model pojęciowy (schemat)

  ┌─────────── K0-TRUTH · Common Source of Truth (§4.3) ───────────┐
  │                                                                │
  │   CLAIM ──has? SOURCE──▶ EVIDENCE ──weryfikacja──▶ STATUS      │
  │     │           │            │                       │         │
  │     └─ brak ────┘            │              ┌────────┴───────┐ │
  │        │                     │              │  FACT/CONFIRMED│ │
  │        ▼                     │              │  ← R2 evidence │ │
  │      [ GAP ] ◀── R5          │              └────────────────┘ │
  │                              ▼                                  │
  │                     audit event + owner  ◀── R6                 │
  │                                                                │
  │   SIMULATION ┈┈ (przestrzeń odseparowana, R3) ┈┈ ≠ operacyjne  │
  │   ROADMAP    ┈┈ (nie produkcyjne, R4/§16)                       │
  │   zamknięcie ── wymaga remediation evidence ◀── R1             │
  └────────────────────────────────────────────────────────────────┘
  
Zasada nadrzędna. K0-TRUTH nie jest tablicą deklaracji — jest bramą. Twierdzenie bez dowodu nie awansuje; incydent bez dowodu naprawy nie zamyka się; komponent bez kodu+testu+endpointu nie jest LIVE. Silnik zamienia doktrynę claim ≤ proof w warunek techniczny, nie w apel o dobrą wolę.
Granica. System K0-TRUTH klasyfikuje i pilnuje statusów prawdy. Nie wykonuje nieautoryzowanych testów, eksploatacji ani hack-backu. Wszelkie działania ofensywne wyłącznie w ramach pisemnego Rules of Engagement. Zero payloadów na tej stronie i w tym module.

← Orchestrator · Evidence Layer → · Doktryna claim ≤ proof · Roadmap dev