Walidacja wyników i audyt

Cel

NORBI ma odróżniać „model odpowiedział” od „rezultat został dowiedziony”. Walidacja jest częścią workflow, a Audit Ledger zachowuje związek między intencją, decyzją, wykonaniem i skutkiem. Audit nie jest bezmyślnym zrzutem wszystkich danych; musi być wystarczający, zredagowany i odporny na manipulację.

Cztery warstwy walidacji

1. Strukturalna — schema, format, wymagane pola, hash, brak korupcji.
2. Techniczna — test, obliczenie, render, lint, checksum, format media, constraints.
3. Semantyczna/domenowa — zgodność z celem, źródłami, prawem procesu, danymi referencyjnymi.
4. Ludzka — jakość, odpowiedzialność, ryzyko, decyzja biznesowa i nieautomatyzowalne wyjątki.

Nie każdy rezultat wymaga wszystkich czterech, ale wybór musi być jawny. Wiadomość FAQ może mieć structured output i source check; umowa wymaga eksperta. Render ma technical QC i creative review. Kod ma testy oraz review diff.

Karta modułu Validation & Audit

Pole	Kontrakt
Odpowiedzialności	validators registry, evidence binding, event chain, redaction, retention, queries i export.
Wejścia	job/tool/artifact/approval events, validator results, policy decisions, receipts.
Wyjścia	pass/fail/warning, evidence bundle, timeline, compliance export, anomaly alert.
Zależności	broker-owned DB, Artifact Store, monotonic IDs/time, hash chain/signature, retention.
Uprawnienia	append przez Control Plane; brak mutacji historycznej; odczyt per rola/classification.
Autonomia	automatyczne blokowanie na hard gate i anomaly alert; brak automatycznego kasowania dowodu.
Walidacja	completeness, referential integrity, chain verification, redaction tests i restore.
Awaria	dispatch stop dla security events, lokalny bufor bounded, reconciliation po odzyskaniu.

Validator Registry

Validator jest wersjonowany jak tool, ale nie musi mieć skutku. Deklaruje input types, profile, thresholds, wynik schema i known blind spots. Ten sam model, który wygenerował treść, może być jednym z recenzentów, ale nie jedynym dowodem dla krytycznego kryterium. Deterministyczna walidacja ma pierwszeństwo tam, gdzie problem jest obliczalny.

Evidence Bundle

Pakiet dowodów zawiera goal/acceptance hash, input artifact versions, tool/model/agent versions, workflow definition, policy, approvals, execution receipts, validator results, output hashes, warnings, reviewer decision i exceptions. Pakiet jest zamrażany przed promotion/publish. Zmiana wyniku tworzy nowy bundle.

Audit Event

Minimalny event: ID, sequence, correlation/project, actor/principal, event type, previous/new state, object IDs/versions, policy version, timestamp brokera, payload/evidence refs, classification i integrity link. Długie treści pozostają artefaktami; log zawiera identyfikatory i hashe. Sekrety są niedozwolone.

sequenceDiagram
    participant I as Intent
    participant P as Policy
    participant H as Human
    participant E as Executor
    participant V as Validator
    participant A as Audit
    I->>A: intent.received
    P->>A: policy.decided
    H->>A: approval.decided
    E->>A: grant.consumed + execution.receipt
    V->>A: validation.result
    A->>A: evidence bundle freeze

Audit UX

Użytkownik może filtrować po projekcie, osobie, agencie, tool, account, destination, state, risk i czasie. Widok „dlaczego?” pokazuje drogę decyzji polityki. Widok „co opuściło urządzenie?” zbiera wszystkie external transmissions. Widok „co się zmieniło?” pokazuje artifacts/diff i approvals. Eksport jest sam w sobie skutkiem klasyfikowanym i może wymagać approvala.

Przykładowe polecenia

• „Pokaż wszystkie zewnętrzne transmisje danych confidential w tym miesiącu.”
• „Zbuduj evidence bundle dla publikacji filmu i wskaż brakujące prawa.”
• „Sprawdź ciąg audytu od wiadomości klienta do wysłanej odpowiedzi.”
• „Znajdź jobs oznaczone succeeded bez wymaganego walidatora.”

Błędy i ryzyka

Ryzyka to log injection, niekontrolowany rozmiar, utrata korelacji, sekret w błędzie, zegar workera, manipulacja retencją i fałszywy „pass” bez dowodu. Czas autorytatywny daje broker, output jest bounded, treść zewnętrzna nie jest typem eventu, a chain/integrity jest okresowo sprawdzana. Sam hash nie dowodzi, że człowiek widział pełną treść; approval zapisuje także disclosure contract.

Scenariusz awaryjny

Jeśli nie można zapisać security-relevant eventu razem z przejściem stanu, przejście jest wycofywane. Brak miejsca w audycie blokuje nowe skutki zanim log się urwie. Po restore integralność i referencje są sprawdzane przed dispatch. Uszkodzony fragment jest zachowany do analizy; nie „naprawia się” go przez usunięcie rekordów.