Procedura

Proces wydawniczy SSOT: release → reindeksacja → regresja

Jeśli baza wiedzy jest produktem, to jej publikacja wymaga wydania. W Luage oznacza to: wersję, bramki i rejestr zmian — w kolejności, bez improwizacji.

Czas czytania: ~10 min Aktualizacja: 2026-01-10

Artefakty obowiązkowe

doc@ver i changelog zakresu zmian.
Review merytoryczne + ACL/DLP.
Build ID indeksu i grafu (blue/green).
Raport regresji (golden set) przed publikacją.

Workflow SSOT: wniosek → review → wersja → reindeksacja → bramka → publikacja.

Założenie: SSOT traktujemy jak kod. Zmiana w dokumencie jest zmianą w produkcie. W konsekwencji: wersjonowanie, review, bramki i rejestr zmian są standardem, nie dodatkiem.

1. Cele procesu

Utrzymać jedno źródło prawdy bez chaosu wersji.
Zapewnić dowodowość: każda teza w odpowiedzi ma czytelny dowód (doc@ver).
Minimalizować regresje: zmiana przechodzi przez golden set i progi akceptacji.

2. Role (minimum)

Rola	Odpowiedzialność
Owner SSOT	Treść merytoryczna, zakres, akceptacja kanoniczności.
Reviewer	Review jakości: spójność, cytowalność, styl, źródła.
Platform	Reindeksacja, build grafu, canary, rollback.
Governance	Polityki (ACL/DLP), wyjątki, audyt.

3. Workflow: od zmiany do publikacji

3.1 Wniosek (ticket/ADR)

Opis: co się zmienia i dlaczego.
Zakres: które rozdziały i jakie przypadki użytkowe.
Owner oraz plan komunikacji (kto musi wiedzieć).

3.2 Review

Review merytoryczny (fakty, definicje, spójność).
Review polityk (ACL/DLP) oraz cytowalności (doc@ver).

3.3 Wersjonowanie

Wersjonowanie ma być jednoznaczne: doc_id@version. Dla zmian redakcyjnych dopuszczalny jest patch, dla zmian znaczeniowych — minor/major.

3.4 Reindeksacja i build grafu

Buduj w trybie blue/green.
Do metadanych dodaj: wersję embedding, chunkingu i ontologii.

3.5 Gate: golden set + progi

Golden set musi obejmować pytania krytyczne dla domeny.
Progi minimalne: retrieval success, evidence coverage, path validity.

3.6 Publikacja i komunikacja

Wpis do Rejestru zmian (data, tytuł, zakres, wpływ).
Ogłoszenie dla interesariuszy: co się zmieniło i jak się to weryfikuje.

4. Tryby wydawnicze

Release planowany — standardowy cykl: review → gate → publish.
Hotfix — pilna poprawka: krótszy review, ale bramki dowodowe pozostają.
Eksperyment — izolowany: feature flag + ograniczony ruch (canary).

5. Typowe awarie procesu

Zmiana SSOT bez aktualizacji indeksu (stare retrieval).
Wersjonowanie bez wpisu w rejestrze (brak audytu).
Publikacja bez golden set (regresje nie są widoczne).

6. Checklista

Ticket/ADR istnieje i ma ownera.
Review (merytoryka + polityki) zakończony.
Wersja dokumentu nadana (doc@ver) i zapisana.
Reindeksacja i build grafu w trybie blue/green.
Golden set przeszedł progi.
Wpis do rejestru zmian + komunikacja.

Po co ten formalizm

Żeby wiedzieć co i kiedy zmieniono.
Żeby mieć porównanie (przed/po) i rollback.
Żeby „dowód” nie był deklaracją, tylko artefaktem.

Powiązane

Cykl życia dokumentów i SSOT Wersjonowanie polityk Rejestr zmian Runbook: odtworzenie Monitoring retrieval i GraphRAG