SOTER
Platforma analityczna, operacyjna i ewolucyjna dla organizacji.
use: to udział. Rzeczywistość jest nadrzędna wobec procedury. Fakty są najpierw rejestrowane (nawet błędne), a dopiero potem interpretowane. Systemy działają w warunkach niepewności, w obcności innych systemów o odmiennych celach i logikach.SOTER nie jest po prostu narzędziem do rysowania diagramów. To cybernetyczny bliźniak organizacji, oparty na rygorze fizycznym i logicznym. Oddziela on „rzecz samą w sobie" (zdarzenie) od „obserwacji" (zapis w Ledgerze). W swojej filozofii stara się znaleźć równowagę między rygorem ontologicznym a pragmatyzmem.
SOTER kategorycznie odrzuca architekturę monolitycznych systemów ERP na rzecz modelu systemu operacyjnego:
.fact)..model..view i .interaction..api). SOTER dostarcza surowy dowód fizyczny transferu masy/energii, a Zewnętrzna Aplikacja nakłada na to logikę prawno-podatkową.Uważamy, że GUI i canvas to pozór kontroli, a tekst to rzeczywista kontrola. Model zapisany kodem jest czytelny, diffowany i semantycznie bogaty. Pliki źródłowe Logos są jedynym „Źródłem Prawdy" (Source of Truth). Diagram jest zawsze artefaktem wygenerowanym z tekstu. Diagramy (np. BPMN, UML) są wyłącznie deterministycznymi "cieniami" rzutowanymi z abstrakcyjnego modelu (projekcjami) poprzez reguły zawarte w regułach projekcji (JSON/YAML jako maszynowe definicje + doc/projections/ dla analityków SOTER).
vague oraz placeholder opisują tzw. biznesową „mgłę wojny" - pozwalają spinać procesy tam, gdzie pełna spójność jeszcze nie istnieje.corrects: [ID]).label:, type:) może wystąpić w definicji elementu tylko raz. Powielenie klucza skutkuje błędem kompilacji.System implementuje rygorystyczny podział na Ontologię, Odczyt (Query), Zapis (Command) i Wymianę Maszynową. Każda warstwa rzeczywistości odpowiada innemu typowi pliku Logos:
.model (Ontologia/Fizyka): Definiuje granice rzeczywistości, tego co może się stać. Reprezentuje twardą logikę biznesową. Zbudowany jest wyłącznie w oparciu o triadę SVO (class: Subject | Action | Object). Abstrahuje od wyglądu i prezentacji.
.view (Lens / Soczewka/UI): Widoki analityczne i diagramy. Interfejs odczytu (RO - tylko do odczytu). Tworzy drzewo logiczne UI definiując co i komu pokazać (np. wybór projekcji diagramu), pozostawiając ostateczny wygląd warstwie Incarnation.
.fact (Ledger / Prawda): Niezmienny, dopisywany (Append-only), kryptograficznie podpisany (Hash Chain) dziennik fenomenów. Odpowiada na pytanie: "Co, kto i kiedy faktycznie zrobił?".
.interaction (Interfejs Ludzki / HMI): Ekran roboczy (RW - read-write) dla użytkowników. Formularze, skanery, przyciski. Zbiera bodźce ze świata fizycznego w celu generowania komend dopisujących fakty do Ledger.
Z powodów praktycznych (wydajność) wydzielono specjalny typ pliku do interakcji machine-to-machine:
.api (Synapsa / Błona): Punkt styku dla Maszyn (M2M). Zbiór Receptorów (wejścia) i Strumieni (wyjścia). Pozbawiony jakiegokolwiek UI, operuje na płaskim formacie danych (np. JSON_lines).| Kierunek zależności ↓ | .model |
.view |
.interaction |
.fact |
|---|---|---|---|---|
.model (Ontologia) |
— | ❌ zakaz | ❌ zakaz | ❌ zakaz |
.view (Odczyt) |
✅ Ref / ❌ Def | — | ❌ brak R/W | ✅ Ref / ❌ Def |
.interaction (Zapis) |
✅ Ref / ❌ Def | ✅ Read-Only | — | ✅ Ref / ❌ Def |
.fact (Ledger) |
❌ zakaz | ❌ zakaz | ❌ zakaz | — |
Legenda:
Architektura pozwala na modułową adopcję w organizacjach:
.model i .view. Służy do semantycznego projektowania procesów, dokumentacji i generowania diagramów w czasie rzeczywistym. Brak bazy danych i rygoru fizyki..fact. Rejestracja zdarzeń w czasie rzeczywistym, tworzenie niezmiennej ścieżki audytowej (bitemporalność)..interaction. Pracownicy używają systemu do codziennej pracy, generując logi prosto z pierwszej linii.W pliku .model definiujemy wyłącznie „fizykę” i architekturę rzeczywistości. Obowiązuje tu triada SVO oraz kategoria Aktywności.
Wszystkie encje/węzły (elementy) w języku Logos należą do jednej z trzech kategorii SVO:
parent:). Relacje między nimi opisuje wyłącznie Relationship.autonomy:true: Podmiot jest „Blackboxem” (Pool w BPMN). Znamy tylko jego wejścia/wyjścia, nie widzimy procesów wewnętrznych.false: Podmiot jest przejrzysty (Lane w BPMN). Widzimy jego działania wewnątrz naszego procesu.parent:), o ile tworzą one jedną fizyczną lub logiczną całość.decision: Definiuje logikę wyjść (out:).alternative: Aktywne dokładnie jedno wyjście.options: Aktywna dowolna liczba wyjść (min. 1).all: Aktywne wszystkie zdefiniowane wyjścia.
Rygor: Akcja nie może zakończyć się stanem „none” – przynajmniej jedno wyjście musi zostać nasycone.
Dla zapewnienia determinizmu projekcji i czystości ontologicznej, każdy w element w .model musi definiować swoją klasę niezależnie od typu:
class: Subject (Podmiot): Suwerenny aktor lub system (np. Organization, Role). Może posiadać autonomy: true (Blackbox/Pool) lub false (Lane). Zakaz zagnieżdżania podmiotów w podmiotach.class: Object (Przedmiot): Pasywny nośnik materii, energii, stanu lub informacji (np. DataArtifact). Możliwa twarda kompozycja fizyczna (parent:).class: Action (Akcja): Wektor zmiany (transformator). Atomowy element przepływu.decision: alternative | options | all), z którego wychodzą zdefiniowane warianty (out:).Aktywność to kategoria nadrzędna (niebędąca słowem kluczowym w Logos), grupująca:
type: w Logos.type: w Logos. Na obecnym etapie rozwoju projektu SOTER przyjmujemy konwencję, że 1 plik .model = 1 Process. Plik .model grupuje akcje, podmioty i przedmioty należące do jednego procesu. Jest to rozwiązanie tymczasowe, które zostanie zrewidowane gdy pojawi się potrzeba jawnej deklaracji procesów.Ontologia zdefiniowana w .model przejawia się w systemie w trzech odrębnych aspektach:
| Aspekt | Typ pliku | Kluczowe elementy | Cel |
|---|---|---|---|
| Ledger (Historia) | .fact |
Fact, Interaction, Declaration |
Zapis niezmiennych fenomenów (co się stało). |
| Lens (Odczyt) | .view |
View, Widget, Perspective |
Projekcja grafu i bilansów dla obserwatora. |
| Interface (Zapis) | .interaction |
Form, Field, Command |
Zbieranie bodźców i generowanie faktów. |
Ten przykład obrazuje nowe reguły: brak kompozycji podmiotów, autonomię (blackbox) oraz logikę decyzji w akcji.
soter v1
# --- PODMIOTY (Asocjacja, nie kompozycja) ---
element u-spedytor-zewnetrzny
type: Subject
name: SpedytorLogistyczny
autonomy: true # Blackbox - nie widzimy jak jadą, interesuje nas fakt dostawy
element u-magazynier-lokalny
type: Subject
name: AdamMagazynier
autonomy: false # Widzimy jego akcje w naszym procesie
# --- OBIEKTY (Kompozycja dozwolona) ---
element u-paczka-zbiorcza
type: Object
name: Paczka
element u-towar-wewnetrzny
type: Object
parent: u-paczka-zbiorcza # Twarda kompozycja przedmiotu
# --- AKCJA Z DECYZJĄ (Atrybut, nie zagnieżdżenie) ---
element u-weryfikacja-dostawy
type: Action
in: [u-paczka-zbiorcza]
out: [u-status-przyjety, u-status-reklamacja]
decision: alternative # Musimy wybrać: albo przyjmujemy, albo reklamujemy
# --- RELACJA N-ARNA (Hyperedge) ---
element r-zespol-logistyczny
type: Relationship
name: GrupaRobocza
# Relacja wiąże wielu aktorów w jeden kontekst bez hierarchii parent-child
source: [u-spedytor-zewnetrzny, u-magazynier-lokalny, u-paczka-zbiorcza]
AdamMagazynier nie jest „dzieckiem” spedytora ani firmy w strukturze pliku. Są suwerenni. Ich współdziałanie określa relacja r-zespol-logistyczny.autonomy: true, Providence wie, że dla Spedytora nie musi (i nie może) weryfikować wewnętrznych bilansów energii – liczy się tylko wynik na „wyjściu” z jego czarnej skrzynki.decision: alternative wymusza na interfejsie .interaction stworzenie logiki, która nie pozwoli zamknąć akcji bez wybrania dokładnie jednej ścieżki wyjściowej.Model wizualny SOTER opiera się na rozróżnieniu między węzłami statycznymi a węzłami przepływu (zbliżonymi do Sieci Petriego):
Subject i Object. To dyskretne stany rzeczywistości. Istnieją obiektywnie, można je policzyć i posiadają swoją masę, informację lub potencjał do działania.Relationship. Wskazują napięcie organizacyjne lub uwarunkowania (np. podległość, kompatybilność) między dwoma węzłami posiadającymi. Nie płynie w nich czas, nie zużywają masy ani energii, definiują wyłącznie architekturę układu.Action. Są to wektory zmiany płynące w czasie. Zasysają materię i podmioty przez operatory wejścia (consume, actor) i transformują je w wyjścia (produce).Model wizualny SOTER opiera się na rozróżnieniu między węzłami statycznymi a węzłami przepływu (zbliżonymi do Sieci Petriego):
Subject i Object. To dyskretne stany rzeczywistości. Istnieją obiektywnie, można je policzyć i posiadają swoją masę, informację lub potencjał do działania.Relationship. Wskazują napięcie organizacyjne lub uwarunkowania (np. podległość, kompatybilność) między dwoma węzłami posiadającymi. Nie płynie w nich czas, nie zużywają masy ani energii, definiują wyłącznie architekturę układu.Action. Są to wektory zmiany płynące w czasie. Zasysają materię i podmioty przez operatory wejścia (consume, actor) i transformują je w wyjścia (produce).W architekturze SOTER rozdzielamy to, co wrodzone, od tego, co jest wynikiem otoczenia, a także rzeczy same w sobie i rzeczy zaobserwowane.
Stan (State): Dotyczy immanentnych (wewnętrznych, niezaleznych od relacji z innymi) cech obiektu (np. masa, numer seryjny, fizyczna usterka). Zbiór właściwości definiujących obiekt niezaleznie od innych. Zmiana stanu wymaga Akcji (Action), która transformuje dany podmiot lub przedmiot w czasie.
Status (Phenomenon/Status): Zjawisko względne, będące jedynie etykietą nadawaną przez Obserwatora na podstawie odczytu powiązań w przestrzeni (graf relacji w .model) lub zdarzeń w czasie (w Ledgerze .fact). Obiekt sam z siebie może "nie wiedzieć" o swoim statusie (np. dokument, że jest "podpisany"). Status to etykieta organizacyjna nadana przez autoryzowany Podmiot (np. Dział Jakości).
Obiekty przed obserwacją mają status nieustalony aż do momentu, gdy zostanie wykonana Akcja, która zmaterializuje ich Status w Ledgerze jako Fakt. Organizacja nie reaguje na procesy fizyczne, lecz na fenomenologiczne qualia.
Kompozycja vs Asocjacja (Wymóg Lintera):
Kompozycja (parent:): Służy wyłącznie do twardej przynależności fizycznej (Part-Of). Stosuje się ją, gdy destrukcja węzła nadrzędnego oznacza absolutną śmierć węzła podrzędnego (np. silnik w konkretnej maszynie).
Asocjacja (Relationship): Służy do wiązania suwerennych bytów organizacyjnych. Przykładowo, struktura raportowania pracownika do kierownika to statyczna krawędź. Jeśli relacja zostaje zerwana, podmioty trwają w systemie nienaruszone, zachowując swój immanentny stan i historię.
W architekturze SOTER rozdzielamy to, co wrodzone, od tego, co jest wynikiem otoczenia:
Action), która transformuje dany podmiot lub przedmiot w czasie..model) lub zdarzeń w czasie (w Ledgerze .fact). Obiekt sam z siebie "nie wie" o swoim statusie (np. pracownik jest "aktywny", dokument jest "podpisany").parent:): Służy wyłącznie do twardej przynależności fizycznej (Part-Of). Stosuje się ją, gdy destrukcja węzła nadrzędnego oznacza absolutną śmierć węzła podrzędnego (np. silnik w konkretnej maszynie).Relationship): Służy do wiązania suwerennych bytów organizacyjnych. Przykładowo, struktura raportowania pracownika do kierownika to statyczna krawędź. Jeśli relacja zostaje zerwana, podmioty trwają w systemie nienaruszone, zachowując swój immanentny stan i historię.Zmysły systemu SOTER (Receptory) traktują sygnały zewnętrze ze ścisłym rygorem:
Błąd Syntaktyczny (Głębokie Ignorowanie): Zły format pliku lub brak klucza. Zmysł jest ślepy. Pakiet jest bezgłośnie odrzucany bez komunikatu błędu, by nie marnować energii (ochrona przed DDoS).
Błąd Semantyczny (Niestrawność): Format jest poprawny, ale treść łamie fizykę (np. wydano 10kg, choć było 5kg). Baza .fact zapisuje zdarzenie bez błędu. Chwilę później asynchroniczny Verifier wykrywa paradoks i "wymiotuje", materializując go jako nowy węzeł w systemie: unresolved_gap (Dług Ontologiczny), wymuszając akcję kompensacyjną Homeostatu.
SOTER dąży do potężnej asynchroniczności, eliminując wąskie gardła komunikacyjne.
Systemy zewnętrzne nadają wysyłanym faktom własny ciąg znaków (np. UUID). SOTER po prostu uwiecznia go w Ledgerze jako string bez nadawania mu logiki.
.api. Jeśli zobaczy swój znacznik z datą recorded_at, ma 100% pewności zapisu.correlation_id i payload są identyczne, SOTER rejestruje to jako echo sygnału (zapis bez wpływu na bilans masy). Jeśli correlation_id jest to samo, ale masy się różnią, Verifier zgłasza błąd zderzenia (Paradoks Semantyczny).Rozdzielenie warstwy analitycznej od projektowej (UX).
priority: critical), wskazuje źródło danych (focus) oraz deklaruje rodzaj projekcji (np. projection: BPMN_Collaboration lub subtype: Table). Nie posiada atrybutów CSS (np. koloru, czcionki)..md (np. BPMN.md, UML.md). Definiują twardy, matematyczny przelicznik: "Każde class: Action + decision: alternative narysuj jako bramkę XOR".SOTER operuje w łańcuchu: Obserwator → Ledger → Verifier → Reconciler → SOPHIA.
Sophia nie zarządza danymi. Sophia mutuje Genotyp (zmienia pliki .model), zamykając proces Double-Loop Learning.
unresolved_gap), generuje pomysły zmian (np. "Dodajmy nowy Subject do sprawdzania jakości") i wstrzykuje te hipotezy do zamkniętego środowiska testowego..api, który zapisuje się jako docelowa mutacja kodu organizacji.Cybernetyczny bezpiecznik sztucznej inteligencji. Praca Sophii kosztuje (cost_basis). Jeśli Sophia-B wykryje, że koszt procesora i energii zużyty na znalezienie optymalizacji przewyższa zysk z jej wdrożenia, układ przerywa pętlę.
self_mismanagement..view dla ludzkiego Zarządu (Sąd nad Sophią), który decyduje o rekonfiguracji parametrów AI.soter check <file> - Checker/walidator syntaktyczny i logiczny grafu (Strict Mode, unikanie nieskończonej pętli).soter verify --ledger <.fact> --model <.model> - Zderzenie historii z Fizyką. Odtworzenie stanu, materializacja luk (Gaps) na żądanie.soter build ui --source <.interaction> - Skompilowanie przepływu do postaci czystego logicznego drzewa UI-AST pod TEST serwer Incarnation.soter trace <uuid> - Zastosowanie natywnej historii Bitemporalnej Hash Chain do wyrysowania "życia" dowolnego elementu od jego materializacji (Birth) aż po wylądowanie w Zlewni (Sink) - zniszczenie elementu lub jego wyprowadzenie poza system organizacji (np. sprzedaż i dostawa do klienta).Tradycyjna księgowość widzi tylko pieniądz po fakcie. SOTER rozróżnia absolutny koszt wytworzenia od subiektywnej wartości rynkowej. Każda aktywność (Activity) musi spełniać rygor MES (Zasadę Zero-Sum):
cost_basis (Koszt absolutny): Wartość ciągniona (surowce + czas + praca). Stała wewnątrz układu. Suma kosztów wejściowych musi równać się sumie wyjściowej ($\sum Cost_{in} = \sum Cost_{out}$).market_value (Przyciąganie Rynku): Potencjał relacyjny. Wartość, jakiej spodziewamy się od rynku. Źródło marży realizowanej poza bilansem fizycznym (np. sprzedaż stołu wyprodukowanego za 1500 PLN za cenę 5000 PLN).unresolved_gap i jest kierowany do Zlewni (Sinks). Jest to jawny dług do wyjaśnienia przez organizację (np. jako odpad). Nic nie dematerializuje się bez śladu.Aktywność to kategoria nadrzędna grupująca elementy „dziania się”. W Logos v1 przepływ jest implikowany (implicit) przez topologię wejść i wyjść.
Rygor Dwudzielności: Akcja nigdy nie łączy się bezpośrednio z inną Akcją. Wyjście (out:) Akcji musi zawsze wskazywać na Object lub Subject (Stan), który następnie staje się wejściem (in:) dla kolejnej Akcji.
Process (Proces): Nie jest listą instrukcji, lecz deklaracją domeny. Grupuje Akcje, które dzielą wspólny kontekst zasobowy. Proces „uruchamia się” samoistnie w silniku Providence, gdy w Ledgerze pojawią się fakty nasycające wejścia jego pierwszej Akcji.
W Logos v1 nie istnieją słowa kluczowe sequence, parallel, fork czy join. Logika przepływu wynika wyłącznie z atrybutu decision oraz topologii grafu:
decision: all lub options), na które czekają różne, niezależne Akcje.in: [O1, O2]). Silnik Providence wstrzymuje materializację tej Akcji, dopóki wszystkie wymagane "tokeny" (Obiekty/Stany) nie zostaną zarejestrowane w Ledgerze.logistyka_magazynowa.model - Przepływ EmergentnyPoniższy kod pokazuje, jak bez ani jednej komendy sterującej tworzymy równoległy proces weryfikacji i pakowania towaru.
soter v1
# --- STANY (Miejsca w grafie dwudzielnym) ---
element u-zamowienie-surowe
type: Object
name: ZamowienieSurowe
element u-towar-sprawdzony
type: Object
name: TowarZweryfikowany
element u-dokument-przewozowy
type: Object
name: EtykietaLogistyczna
# --- AKCJE (Transformacje / Węzły tranzycyjne) ---
# Rozwidlenie (Fork) - produkuje dwa obiekty jednocześnie
element a-procesowanie-zamowienia
type: Action
in: [u-zamowienie-surowe]
out: [u-towar-sprawdzony, u-dokument-przewozowy]
decision: all # Tworzy oba obiekty: fizyczny i informacyjny
# Te dwie akcje zadzieją się równolegle, bo mają nasycone wejścia
element a-pakowanie-fizyczne
type: Action
in: [u-towar-sprawdzony]
out: [u-paczka-gotowa]
element a-generowanie-tracking-no
type: Action
in: [u-dokument-przewozowy]
out: [u-status-nadano]
# Złączenie (Join) - wymaga obu stanów, by wysłać towar
element a-wydanie-kurierowi
type: Action
in: [u-paczka-gotowa, u-status-nadano] # Czeka na oba tokeny
out: [u-potwierdzenie-odbioru]
Komentarz Lintera: Powyższy kod Logos v1 nie zawiera żadnej instrukcji "najpierw A, potem B". To topologia obiektów u-towar-sprawdzony i u-dokument-przewozowy narzuca kolejność. Jeśli a-procesowanie-zamowienia nie wyprodukuje etykiety, a-wydanie-kurierowi nigdy nie zaistnieje w Ledgerze. To jest "fizyka", a nie "procedura".
Tradycyjna księgowość widzi tylko pieniądz po fakcie. SOTER rozróżnia absolutny koszt wytworzenia od subiektywnej wartości rynkowej. Każda aktywność (Activity) musi spełniać rygor MES (Zasadę Zero-Sum):
cost_basis (Koszt absolutny): Wartość ciągniona (surowce + czas + praca). Stała wewnątrz układu. Suma kosztów wejściowych musi równać się sumie wyjściowej ($\sum Cost_{in} = \sum Cost_{out}$).market_value (Przyciąganie Rynku): Potencjał relacyjny. Wartość, jakiej spodziewamy się od rynku. Źródło marży realizowanej poza bilansem fizycznym (np. sprzedaż stołu wyprodukowanego za 1500 PLN za cenę 5000 PLN).unresolved_gap i jest kierowany do Zlewni (Sinks). Jest to jawny dług do wyjaśnienia przez organizację (np. jako odpad). Nic nie dematerializuje się bez śladu.SOTER nie odrzuca zdarzeń, które nie pasują do modelu (podejście "Save-first, then interpret"). Baza (Ledger) przyjmuje każdy syntaktycznie poprawny sygnał. Zderzenie sygnału z rzeczywistością (weryfikacja semantyczna) następuje asynchronicznie, materializując ewentualne błędy jako jawny Dług Ontologiczny.
unresolved_gap (Dług Ontologiczny) dla brakujących 2 sztuk..view, stanowiący realny dług do wyjaśnienia przez organizację, a nie jedynie "techniczny błąd bazy danych".occurred_at (czas deklarowany/subiektywny powstawania) od recorded_at (czas obiektywnego zapisu na serwerze).corrects: [ID]): Historia w Ledgerze jest nienaruszalna. Pojawienie się faktu z atrybutem corrects wskazuje na błędny wpis i unieważnia jego logiczne skutki, ale oba fakty zostają w Ledgerze. Każdy fakt w .fact jest powiązany kryptograficznie z poprzednikiem (Hash Chain).System procesuje fakty w zamkniętej pętli logicznej: Observer → Ledger → Verifier → Reconciler → Observer.
recorded_at oraz kryptograficzny hash. Kolejność zapisu to bezwzględne FIFO.prev_hash)..model. Sprawdza poprawność bilansów (fizyka biznesu).SOTER nie odrzuca zdarzeń niezgodnych z modelem, lecz rejestruje je jako fakty do późniejszej interpretacji.
Każdy fakt w Ledgerze posiada strukturę SVO i należy do jednego z trzech typów:
trigger (akcja), actor (podmiot), oraz operatory consume (wejście) i produce (wyjście).focus (byt, którego dotyczy) i signal (typ sygnału/anomalii).focus, attribute i value.Operatory consume: i produce: obsługują bitemporalną księgowość ontologiczną bytów:
produce bez consume. Nowy UUID materializuje się w rzeczywistości SOTER.consume i produce. Byt zmienia atrybuty (np. status z „przeterminowany” na „utylizacja”) przy zachowaniu tożsamości.consume bez produce. Zasób przestaje istnieć w puli dostępnej i trafia do bilansu entropii.occurred_at (czas zajścia w świecie) od recorded_at (czas zapisu w Providence).corrects: [ID]): Historia jest nienaruszalna. Nowy fakt unieważnia skutki poprzedniego, ale oba pozostają w Ledgerze powiązane w Hash Chain.System trwa w stanie ciągłego nadzoru w zamkniętej pętli logicznej: Observer → Ledger → Verifier → Reconciler → Observer.
Verifier (Audytor): Zderza fakty z modelem, sprawdzając fizykę biznesu. Reconciler (Silnik Logiki): Materializuje Fakt Dorozumiany (Dług Ontologiczny), jeśli wykryje lukę w bilansie.
Logika biznesowa znajduje się w 100% w plikach .model. Masywne obliczenia (np. wyliczanie tras, skanowanie heurystyczne danych, generowanie PDF) są delegowane:
Subject (atrybut kind: system). Webhooki i API należą do definicji podmiotu.mode: atomic (Synchronous): Wynik wymagany natychmiast. UI zablokowane na czas odpowiedzi.mode: detached (Asynchronous): Aktywność długotrwająca. Providence zwalnia zasoby, system czeka na fakt asynchroniczny. Brak odpowiedzi w wymaganym czasie (timeout) generuje Dług Ontologiczny (time_violation).Providence bada deltę czasu między startem a zakończeniem aktywności w .fact i doradza optymalizację Inżynierowi Organizacji (np. przez Linter w VS Code):
atomic na detached, jeśli akcja notorycznie przekracza próg blokowania UI (np. >3s).detached na atomic, jeśli akcja wykonuje się niemal natychmiastowo (<100ms), redukując narzut architektoniczny..view poddawane są generacji w locie wymuszając standardy (np. soter2sequence_uml)..view. Muszą operować w plikach .interaction.Logos realizuje postulat ekstremalnego minimalizmu. Wszystkie pojęcia (węzły) grafu są definiowane za pomocą uniwersalnego słowa kluczowego element. O ich semantyce decyduje obowiązkowy atrybut type:.
| Słowo Kluczowe | Opis | Przykładowe Atrybuty | Wymagane w plikach |
|---|---|---|---|
| element | Uniwersalny budulec grafu. | type:, name:, description: |
Wszystkie |
| include | Dołączanie innych plików Logos. | include "common.model" |
Wszystkie |
| alias | Definiowanie skrótów dla typów lub nazw. | alias Action as A |
Wszystkie |
| soter v1 | Nagłówek wersji (wymagany w 1. linii). | - | Wszystkie |
| Atrybut | Opis | Przykład / Wartości |
|---|---|---|
| type: | Obowiązkowy. Definiuje naturę elementu. | Fact, Action, Subject, Object, View, Relationship, Decision, Widget, Form, Field |
| name: | Ludzka nazwa techniczna (CamelCase). | name: MojaFirma (Linter zabrania cudzysłowów) |
| description: | Semantyczny opis biznesowy. | description: "Opis..." (Zawsze w cudzysłowie) |
| parent: | Jawne wskazanie nadrzędności (opcjonalne). | parent: u-firma-matka |
| source: | Wskazanie modelu źródłowego dla widoku. | source: fabryka.model |
| source / target | Definicja krawędzi dla relacji. | source: u-A, target: u-B |
type: Decision): Muszą być zagnieżdżone w strukturze elementu typu Action lub Activity.type:.type: Widget o podtypie wizualnym).type:, name: i description: pojawiały się jako pierwsze atrybuty w bloku.fabryka_mebli.model - Ontologia i Fizykasoter v1
# --- PODMIOTY ---
element u-stolarz-jan()
type: Subject
name: JanStolarz
description: "Operator obsługujący maszynę do cięcia"
autonomy: true
role: "Operator Maszyny"
# --- ZASOBY ---
element u-drewno-debowe()
type: Object
name: DrewnoDebowe
description: "Surowiec główny"
category: matter
nature: physical
medium: kg
element u-stol-debowy()
type: Object
name: StolDebowy
description: "Gotowy produkt"
category: matter
nature: physical
medium: sztuka
mass: 50 kg
# --- AKCJE I DECYZJE ---
element u-produkcja-stolu()
type: Activity
name: ProdukcjaStolu
description: "Transformacja drewna w stół"
intent: "Produkcja"
in: [u-drewno-debowe, u-roboczogodzina]
out: [u-stol-debowy]
# Zagnieżdżona decyzja
element d-kontrola-jakosci()
type: Decision
description: "Czy stół spełnia normy?"
options: [Passed, Failed]
panel_produkcyjny.interaction - Interfejs Zapisowysoter v1
element PanelRaportowania
type: Interaction
source: fabryka_mebli.model
element RaportujUkonczenie
type: Form
trigger: u-produkcja-stolu
element f-drewno
type: Field
label: "Zużyto Drewna (kg)"
bind: u-drewno-debowe.amount
scenariusz_produkcyjny.fact - Dziennik ZdarzeńSymulacja rzeczywistości: od zapisu zużycia, przez korektę błędu, aż po automatyczną kompensację długu ontologicznego.
soter v1
# Przykład interakcji: Produkcja (Transformacja drewna w stół)
# 1. Jan raportuje zużycie 40kg drewna, ale myli się w ilości (rzeczywiście zużyto 60kg)
element f-prod-001
type: Fact
subtype: Interaction
occurred_at: 2026-03-12T15:00:00
trigger: u-produkcja-stolu
actor: u-stolarz-jan
consume: [u-drewno-debowe: [amount=60, unit=kg]]
produce: [u-stol-debowy: [amount=1, unit=szt]] # Z .model wiemy, że u-stol-debowy = 50 kg
# 2. Providence (Reconciler) widzi stratę i domyka bilans faktem dorozumianym
element f-gap-002
type: Fact
subtype: logical_compensation
recorded_at: 2026-03-12T15:10:01
trigger: f-prod-001
produce: [u-trociny-debowe: [amount=10, unit=kg]] # 60 kg = 50 kg + 10 kg
description: "Automatyczna rejestracja luki ontologicznej"
# 3. Jan koryguje raport po zauważeniu błędu
element f-doc-003
type: Fact
occurred_at: 2026-03-12T15:10:00
corrects: f-001
trigger: u-produkcja-stolu
consume: [u-drewno-debowe: [amount=60, unit=kg]]
produce: [u-stol-debowy: [amount=1, unit=szt]]
waste: [u-trociny-debowe: [amount=10, unit=kg]] # 10 kg "ucieka" jako odpad
dashboard.view - Dashboard (Read-Only)soter v1
element DashboardView
type: View
source: fabryka_mebli.model
layout: grid_2_columns
element w-rentownosc
type: Widget
subtype: Gauges
title: "Rentowność"
focus: u-stol-debowy
| ID | Type | Occurred At | Recorded At | Corrects | Input | Output | Status |
|---|---|---|---|---|---|---|---|
| f-prod-001 | Fact | 15:00:00 | 15:00:05 | — | 60 kg | 1 szt | :ok: OK |
| f-gap-002 | L-Comp | 15:01:00 | 15:01:05 | — | 0 kg | 10 kg | :warning: Gap |
| f-doc-003 | Fact | 16:40:00 | 16:40:04 | f-prod-001 | 60 kg | 1 szt + 10 kg | :ok_hand: Corrected |
f-prod-001 i powie: „Jan zużył 60kg drewna, ale wyprodukował tylko 1 stoł, który ma masę 50 kg. Brakuje masy odpowiadającej 10 kg surowca (drewna)”.f-gap-002 i prześle go do ObserveraDashboardView spadnie o 10%.f-doc-003 i dopisze go do Ledgera, korygując brakującą masę do kategorii odpadów/strat.DashboardView wzrośnie o 10% do wartości oczekiwanej.struktura_organizacyjna.model - Topologia Grafu i HierarchiaPrzykład ilustrujący oddzielenie węzłów suwerennych (Subject) od ich zewnętrznych uwarunkowań (Relationship) oraz wektorów zmiany płynących w czasie (Activity).
soter v1
# --- WĘZŁY STATYCZNE (Masa, Energia, Pamięć) ---
# Immanentne, dyskretne byty istniejące w przestrzeni organizacyjnej.
element u-stolarz-jan
type: Subject
name: JanStolarz
description: "Węzeł wykonawczy - Stolarz (niezależny byt, brak parent:)"
element u-kierownik-anna
type: Subject
name: AnnaKierownik
description: "Węzeł zarządczy - Kierownik zmiany (niezależny byt)"
# --- KRAWĘDZIE STATYCZNE (Przestrzeń / Uwarunkowania / Status) ---
# Napięcia organizacyjne. Nie konsumują zasobów, definiują kauzalny status.
element r-podleglosc-sluzbowa
type: Relationship
name: RaportujeDo
source: u-stolarz-jan
target: u-kierownik-anna
description: "Definiuje status organizacyjny; możliwa do usunięcia bez niszczenia podmiotów"
# --- WĘZŁY TRANZYCYJNE (Czas / Potencjał Transformacji) ---
# Akcje, które po zmaterializowaniu w Ledgerze (.fact) staną się wektorami zmiany.
element u-spotkanie-doradcze
type: Activity
name: SpotkanieDoradcze
description: "Proces transformujący/konsumujący czas podmiotów"
intent: "Optymalizacja pracy"
in: [u-stolarz-jan, u-kierownik-anna] # Wymaga połączenia tych węzłów w czasie
Wyjaśnienie (syntaktyki i semantyki): Powyższy model idealnie zachowuje czystość ontologiczną. JanStolarz i AnnaKierownik to węzły suwerenne. Nie użyto tu zgubnego w tym przypadku atrybutu parent:. Ich podległość została wyabstrahowana do osobnego elementu Relationship – dzięki temu, jeśli w przyszłości wygenerujemy w Ledgerze Fakt zerwania tej relacji, zachowamy spójność historii obu pracowników. Z kolei element SpotkanieDoradcze obrazuje Akcję: to dopiero tutaj, a nie w relacji, następuje przepływ czasu i potencjalna konsumpcja zasobów (np. roboczogodzin) badana przez weryfikator (Verifier).
Zestawienie terminologii technicznej i biznesowej wykorzystywanej w architekturze nowoczesnych systemów informatycznych.
| Termin / Akronim | Rozwinięcie / Znaczenie | Krótki Opis |
|---|---|---|
| API | Application Programming Interface | Interfejs programistyczny do wymiany danych między systemami. |
| ASCII | American Standard Code for Information Interchange | Standard kodowania znaków (wymagany dla identyfikatorów Logos). |
| AST | Abstract Syntax Tree | Drzewo składniowe reprezentujące strukturę kodu (użyte jako UI-AST). |
| Bitemporality | Modelowanie bitemporalne | Technika zapisu uwzględniająca czas wystąpienia faktu oraz czas jego rejestracji. |
| BPMN | Business Process Model and Notation | Graficzny standard opisu procesów biznesowych (odniesienie do Pool/Lane). |
| CamelCase | Camel Case | Sposób zapisu nazw bez spacji, gdzie każdy nowy wyraz zaczyna się wielką literą. |
| CLI | Command Line Interface | Interfejs wiersza poleceń służący do interakcji z systemem (SOTER CLI). |
| CQRS | Command Query Responsibility Segregation | Architektura rozdzielająca operacje modyfikujące (Zapis) od odczytu (Projekcja). |
| DSL | Domain Specific Language | Język dedykowany dla konkretnej dziedziny (Logos jako DSL organizacji). |
| Entropia | Entropia | Miara nieuporządkowania układu; w SOTER monitorowana jako ubytek masy/energii. |
| ERP | Enterprise Resource Planning | System do zarządzania zasobami (SOTER jako funkcjonalny odpowiednik ERP). |
| Fenomenologia | Fenomenologia | Nurt badający zjawiska takimi, jakimi się jawią; podstawa zapisu zdarzeń (faktów). |
| FIFO | First-In, First-Out | Zasada kolejkowania: "pierwszy wszedł, pierwszy wyszedł" (użyta przy Obserwatorze). |
| Hash Chain | Łańcuch skrótów | Struktura danych zapewniająca niezmienność zapisu poprzez kryptograficzne powiązania. |
| HMI | Human-Machine Interface | Interfejs interakcji człowieka z maszyną (np. panel produkcyjny). |
| Homeostaza | Homeostaza | Zdolność systemu do utrzymywania stabilnych parametrów w zmiennym środowisku. |
| I18n | Internationalization | Przystosowanie systemu do obsługi wielu języków (atrybuty @lang). |
| Immutability | Niezmienność | Zasada zakładająca, że raz zapisany stan (np. w Ledgerze) nie może zostać zmodyfikowany. |
| JIT | Just-In-Time | Technika generowania lub kompilacji w momencie zapotrzebowania (np. widoki analityczne). |
| MES | Manufacturing Execution System | System operacyjnego zarządzania produkcją (fundament rygoru rozliczania pętli). |
| Negentropia | Ujemna entropia | Miara uporządkowania i organizacji informacji w systemie cybernetycznym. |
| Portable Document Format | Standardowy format dokumentów cyfrowych (odniesienie do zapisu stanu Memory). | |
| Prakseologia | Prakseologia | Teoria sprawnego działania; podstawa logiczna akcji i aktywności w systemie. |
| SDK | Software Development Kit | Zestaw narzędzi deweloperskich wspierających budowę rozwiązań w oparciu o silnik. |
| SQL | Structured Query Language | Język zapytań do baz danych (odniesienie do nośników informacji cyfrowej). |
| SVO | Subject, Verb, Object | Podstawowa triada semantyczna (Podmiot - Akcja - Przedmiot) używana do opisu rzeczywistości. |
| Teleologia | Teleologia | Badanie celowości działań; podstawa atrybutu intent (zamiar/cel). |
| UML | Unified Modeling Language | Standard wizualizacji struktur programistycznych (odniesienie do diagramów sekwencji). |
| UUID | Universally Unique Identifier | Uniwersalny, unikalny identyfikator techniczny nadawany każdemu elementowi grafu. |
| VSCode | Visual Studio Code | Popularne środowisko programistyczne, dla którego SOTER dostarcza rozszerzenie Logos. |
| Asynchroniczność | Asynchroniczność | Model działania, w którym system nie czeka na natychmiastową odpowiedź (mode: detached). |
| Cybernetyka | Cybernetyka | Nauka o sterowaniu i komunikacji w systemach (fundament SOTER). |
| Fenotyp | Fenotyp | Widzialna/operacyjna postać systemu (diagramy, bazy, UI) wynikająca z Genotypu. |
| Fraktal | Fraktalność | Cecha struktury, która jest samopodobna na różnych poziomach skali (zagnieżdżanie). |
| Funkcja | Funkcja | Przekształcenie wejść w wyjścia; matematyczna natura Akcji. |
| Genotyp | Genotyp | Pierwotny zapis instrukcji systemu (kod Logos). |
| Graf | Graf | Struktura danych składająca się z węzłów (elementy) i krawędzi (relacje). |
| GUI | Graphical User Interface | Graficzny interfejs użytkownika (traktowany jako projekcja/widok). |
| Hollow Client | Hollow Client | "Pusta" aplikacja kliencka, która jedynie renderuje instrukcje z serwera (Incarnation). |
| JIT | Just-In-Time | Generowanie artefaktów (np. widoków) w momencie zapotrzebowania. |
| Logika dwuwartościowa | Logika dwuwartościowa | System logiczny oparty na Prawdzie i Fałszu, używany przez Reconcilera. |
| Metabolizm | Metabolizm | Cykl przetwarzania faktów i energii wewnątrz silnika (Runtime). |
| Mgła wojny | Mgła wojny | Stan niepełnej wiedzy o systemie, modelowany przez vague i placeholder. |
| Milestones | Poziomy wdrożenia | Etapy adopcji systemu (Level 1-4). |
| Ontologia | Ontologia | Dziedzina zajmująca się bytami i ich relacjami (struktura pliku .model). |
| Paradygmat | Paradygmat | Przyjęty sposób widzenia rzeczywistości (tu: cybernetyczno-termodynamiczny). |
| Realizm idealistyczny | Realizm idealistyczny | Nurt uznający nadrzędność idei/modelu nad jego materialną reprezentacją. |
| Runtime | Runtime | Środowisko uruchomieniowe (silnik Providence). |
| Semantyka | Semantyka | Znaczenie elementów i ich atrybutów w kontekście biznesowym. |
| Strzałka czasu | Strzałka czasu | Zasada nieodwracalności zdarzeń (faktów) w Ledgerze. |
| Synchroniczność | Synchroniczność | Model działania, w którym wynik jest wymagany natychmiast (mode: atomic). |
| Syntaktyka | Składnia / Syntaktyka | Reguły budowy poprawnych wyrażeń w języku (Logos Parser). |
| Termodynamika | Termodynamika | Prawa przepływu energii i masy (zasada zachowania w modelu). |
| UI | User Interface | Interfejs użytkownika; w SOTER zawsze wynikający z modelu. |
| WebSocket | Protokół komunikacyjny | Standard dwukierunkowej, asynchronicznej komunikacji między klientem a silnikiem. |
Fact musi być weryfikowalny względem modelu w .model.