Model • Wdrożenie i governance

Wersjonowanie polityk

Jak utrzymywać polityki jak oprogramowanie: SemVer, changelog, testy, rollout, deprecjacja i jawne wyjątki z terminem wygaśnięcia.

Powiązane: Rejestr zmian Powiązane: Rejestr wyjątków

Wersjonowanie jako mechanizm kontroli ryzyka

Polityka językowa, polityka narzędzi, polityka źródeł i polityka bezpieczeństwa nie mogą być „zmieniane z ręki”. Wersjonowanie zapewnia powtarzalność, umożliwia rollback i pozwala wiązać wynik z konkretną wersją reguł.

Jakie wersjonowanie ma sens

  • SemVer dla kontraktów (narzędzia, schematy odpowiedzi): MAJOR/MINOR/PATCH.
  • Date-based dla polityk redakcyjnych i operacyjnych (np. 2026.01.1).
  • Hash jako identyfikator techniczny (do audytu i deterministycznego cache).

Kompatybilność wsteczna i „okna migracji”

Największy błąd to publikacja „breaking change” bez okna migracji. Klasyczny standard:

  • Publish wersję n+1 jako kompatybilną (obsługuje n i n+1).
  • Shadow uruchom testy regresji na ruchu (lub golden set).
  • Cutover przełącz domyślną wersję.
  • Deprecate poprzednią wersję z datą wycofania.

Artefakty, które powinny istnieć

  • Changelog (co zmieniono i dlaczego).
  • Migration notes (co trzeba poprawić w narzędziach, promptach, dokumentach).
  • Owner (RACI) i ścieżka zatwierdzania.
  • Test evidence: wyniki regresji i checklista ryzyk.
Praktyka Compendium: każda odpowiedź (lub decyzja) powinna móc zwrócić policy_version. Bez tego nie ma audytu i nie ma rzetelnego debugowania.

Proponowany format metadanych

policy_meta:
  id: "language.standard"
  version: "2.1.0"
  effective_from: "2026-01-05"
  owner: "Head of CX"
  approvals: ["Legal", "Security"]
  change_type: "MINOR"
  notes: "doprecyzowanie SLA + zamienniki terminów"
W skrócie
  • Polityka jest artefaktem: ma wersję, ownera, changelog i testy.
  • SemVer działa: patch = doprecyzowanie, major = zmiana kontraktu.
  • Deprecjacja wymaga okresu przejściowego i planu migracji.
  • Wyjątki są jawne i czasowe — w rejestrze wyjątków.

1. Definicje: co wersjonujemy

W Luage wersjonuje się nie tylko prompt. Wersjonowane są:

  • polityki (zasady),
  • standard językowy (terminologia, styl),
  • szablony (kontrakty formatu),
  • indeksy wiedzy (SSOT@ver),
  • kontrakty narzędzi (Tool Gateway).

2. SemVer dla polityk

SemVer jest pragmatyczny: wersja komunikuje ryzyko. Minimalna interpretacja:

  • PATCH — doprecyzowanie, bez zmiany zachowania (np. przykład, definicja).
  • MINOR — rozszerzenie kompatybilne (nowa reguła opcjonalna, nowy typ wyjątku).
  • MAJOR — zmiana kontraktu (nowa bramka, obowiązkowe pole, zmiana definicji „done”).

3. Proces zmiany

  1. Propozycja (ADR / issue): powód i wpływ.
  2. Testy: golden set + regresje.
  3. Rollout: canary / feature flag / stopniowe włączanie.
  4. Changelog: jawny opis zmiany.
  5. Deprecjacja: okres przejściowy i migracja.

4. Oś czasu (demonstrator)

Poniższy demonstrator pokazuje, jak może wyglądać ewolucja jednej polityki (przykład).

Demonstrator wersjonowania
Przesuń suwak — zobacz co się zmienia i dlaczego.
policy.language.standard v1.0.0

5. Wyjątki i zgodność

Jeśli część organizacji nie może przejść na nową wersję (np. system legacy), dopuszcza się wyjątek. Warunek: wyjątek ma ownera, ryzyko, mitygację i termin wygaśnięcia.

6. Checklist

  • Polityka ma wersję, ownera i plan przeglądu.
  • Zmiana ma testy i regresje.
  • Jest changelog oraz mechanizm deprecjacji/migracji.
  • Wyjątki są jawne, czasowe i monitorowane.
Powiązane
Na tej stronie
Spis
    Nawigacja
    ← Poprzedni Następny →
    Status merytoryczny
    Metryka (wersja, owner, terminy przeglądu) jest wypełniana automatycznie na podstawie manifestu.