k0nsult.cloud / ai-truth / ipIII / orchestrator / signed-evidence

Signed Evidence & Formal Proof — spec warstwy dowodowej

Dziś każdy evidence-package i board-pack ma hash SHA-256 dowodzący niezmienności treści — to działa (LIVE). Ta strona to spec tego, dokąd zmierza warstwa dowodowa: podpis PAdES + znacznik czasu TSA, niezmienny łańcuch audytu (hash-chain), evidence vault z legal hold oraz Verify v2. Wszystko poniżej hasha jest oznaczone jawnie jako ROADMAP — nie udajemy, że już to mamy.

Orchestrator Roadmap dev Status matrix Connectors Legal Engine DORA / TIBER Signed Evidence Znane ograniczenia ← ipIII hub

Uczciwa granica. Hash SHA-256 dowodzi, że treść pliku nie została zmieniona — ale nie jest kwalifikowanym podpisem elektronicznym ani zaufanym znacznikiem czasu. To dokładnie ta różnica, którą ta spec zamyka. Zgodnie z doktryną claim ≤ proof: element działający oznaczamy LIVE, a projektowany — ROADMAP. Nie ma tu funkcji „na wyrost".

1 element LIVE. 4 elementy ROADMAP. Zero mieszania.

Dziś: package_sha256 + chain-of-custody zapisany w PostgreSQL (dowodliwy MVP). Cel: nadać dowodom wartość formalną poprzez podpis PDF, zaufany znacznik czasu i niezmienny łańcuch audytu, aby audytor, bank SIFI czy organ mógł zweryfikować autentyczność bez zaufania do naszej infrastruktury. To spec — szkielet kierunku, nie deklaracja gotowej funkcji.

OŚ DOWODU: hash SHA-256 (dziś)→podpis PAdES + TSA→hash-chain append-only→evidence vault + legal hold→Verify v2

Rejestr elementów — element / stan / cel / status

Kolumna Status = priorytet: P1 wymagane dla banku/partnera, nie blokuje pilota · P2 hardening późniejszy. Data weryfikacji: 2026-07-05. Doktryna claim ≤ proof.

Element	Stan dziś	Cel (spec)	Status
Integralność treści	Hash `SHA-256` każdego evidence-package / board-pack; `package_sha256` + chain-of-custody w PostgreSQL. Weryfikacja przez /verify.	Utrzymać jako fundament pod podpis i znacznik czasu — hash pozostaje bazą, na której osadza się PAdES/TSA.	LIVE P1
Podpis PDF (PAdES) + TSA	Brak podpisu i znacznika czasu — jest tylko hash integralności. Wartość formalno-prawna słabsza.	Podpis PAdES (PDF Advanced Electronic Signatures) + zaufany znacznik czasu TSA wg RFC 3161; docelowo warstwa podpisu odpornego kwantowo (PQC). Cel: kwalifikowana autentyczność dowodu.	ROADMAP P1
Immutable audit hash-chain	Audit-log w PostgreSQL (append), ale bez kryptograficznego łańcucha — wpisy nie są spięte hashem poprzednika.	Łańcuch append-only, gdzie każdy wpis zawiera hash poprzedniego (hash-chain / Merkle) — wykrywalność każdej modyfikacji lub usunięcia wstecz. Szkielet: kotwiczenie okresowego korzenia.	ROADMAP P1
Evidence vault + legal hold	Pliki i pakiety w bazie/warstwie hostingu; brak dedykowanego magazynu z blokadą retencji.	Magazyn dowodów zgodny z S3 (object storage) z trybem write-once / object lock i legal hold — obiekt niemodyfikowalny do zwolnienia blokady; retencja per polityka. Wsparcie dla postępowań.	ROADMAP P2
Verify v2	/verify potwierdza dziś zgodność hasha SHA-256 przesłanego pakietu.	Upload PDF / JSON / manifest → jednoczesna weryfikacja podpisu + znacznika czasu + chain-of-custody; czytelny raport „co potwierdzone, co nie". Bez JS po stronie klienta wymaganego do samej weryfikacji serwerowej.	ROADMAP P1

Skrót stanu

LIVE

Hash SHA-256 + chain-of-custody w DB

ROADMAP (spec)

PAdES/TSA · hash-chain · vault · Verify v2

P1 — dla banku/partnera

PAdES · hash-chain · Verify v2

5/5

Jawnie oznaczone

żaden ROADMAP nie udaje LIVE

Jak to składa się w dowód (spec)

1 · Integralność (LIVE). Pakiet dostaje hash SHA-256; treść nie może być zmieniona niezauważenie. To jest dziś.

2 · Autentyczność (ROADMAP). Podpis PAdES wiąże pakiet z wystawcą; znacznik TSA dowodzi „istniał przed czasem T". Cel — nie działa jeszcze.

3 · Nienaruszalność historii (ROADMAP). Hash-chain spina wpisy audytu, więc usunięcie/edycja wstecz jest wykrywalna. Szkielet.

4 · Zachowanie dla postępowań (ROADMAP). Evidence vault z object-lock i legal hold utrzymuje dowód niemodyfikowalny na czas sprawy.

5 · Weryfikacja (ROADMAP). Verify v2 pozwala odbiorcy samodzielnie sprawdzić podpis, czas i chain-of-custody bez zaufania do nas.

Czego ta strona NIE deklaruje

To spec, nie gotowa funkcja. Poza hashem SHA-256 (LIVE) żaden element podpisu, łańcucha, vaultu ani Verify v2 nie jest jeszcze wdrożony — są opisane jako ROADMAP, bo nie mamy na nie dowodu (kod + test + endpoint). To wsparcie kierunku architektonicznego, nie obietnica działania dziś.

„100%" u nas znaczy pokrycie dowodowe, nie nieprzenikalność. Deklarujemy tyle, ile potrafimy pokazać. Hash dowodzi niezmienności treści — ale sam nie jest podpisem elektronicznym. Dopóki PAdES/TSA są w spec, mówimy o nich jako ROADMAP, a nie jako o funkcji.

Granica etyczna i prawna. ipIII jest narzędziem obrony i zgodności (GRC/blue). Warstwa dowodowa i wszelkie mapowania obowiązków to wsparcie decyzji (decision-support), nie porada prawna — kwalifikowana wartość dowodu podlega ocenie radcy/kancelarii i właściwego organu. Materiały testowe i przykłady oparte na danych syntetycznych; działania o charakterze testu bezpieczeństwa wyłącznie w granicach pisemnych Rules of Engagement.

Powiązane: weryfikacja pakietu dziś → /verify · pełny rejestr granic dojrzałości → /known-limitations · macierz statusów wszystkich elementów → /status-matrix.