Mapa systemu¶

Architektura warstwowa¶

NORBI rozdziela rozmowę, decyzję, wykonanie i dowody. To rozdzielenie jest ważniejsze niż wybór frameworka czy modelu. Awaria albo kompromitacja warstwy propozycji nie może automatycznie prowadzić do skutku, a worker wykonawczy nie powinien sam decydować, jakie uprawnienia posiada.

flowchart TB
    subgraph UX["Warstwa doświadczenia"]
      CHAT["Chat"]
      CC["Control Center"]
      PWA["PWA / telefon"]
      VOICE["Głos i kanały"]
    end
    subgraph OR["Warstwa orkiestracji"]
      CORE["Norbi Core"]
      PLAN["Planner"]
      ROUTE["Router agentów i modeli"]
      CTX["Context Builder"]
    end
    subgraph CP["Control Plane"]
      JOB["Job / Workflow Broker"]
      POLICY["Policy + Capability Engine"]
      APPROVE["Approval Broker"]
      REG["Registries"]
      AUDIT["Audit Ledger"]
    end
    subgraph EX["Execution Plane"]
      SCHED["Resource Scheduler"]
      WORK["Workers"]
      RUN["Tool Runner"]
      ADAPT["Adapters"]
    end
    subgraph DATA["Dane i dowody"]
      ART["Artifact Store"]
      MEM["Memory Core"]
      DB["Durable state"]
      OBS["Telemetry / receipts"]
    end
    UX --> OR --> CP --> EX
    DATA <--> OR
    DATA <--> CP
    EX --> DATA
    APPROVE -. "kanał operatora" .-> CC

Warstwa doświadczenia¶

Udostępnia różne widoki tego samego stanu, nie osobne systemy prawdy. Czat służy do intencji i wyjaśnień. Jobs pokazują postęp. Approvals przedstawiają skutki. Artifacts pokazują wyniki. Telefon jest ograniczonym klientem Control Plane. Kanały przychodzące tworzą zdarzenia i drafty, lecz nie uzyskują praw wykonawczych.

Warstwa orkiestracji¶

Norbi Core interpretuje zadanie i decyduje, czy wystarczy odpowiedź, narzędzie, agent czy workflow. Context Builder składa minimalny pakiet danych, uwzględniając projekt, pamięć, role i klasyfikację. Planner tworzy DAG z kryteriami ukończenia. Router wybiera wykonawców na podstawie profilu możliwości, kosztu, prywatności, opóźnienia i dostępności.

Control Plane¶

Tu istnieje prawda o stanach, polityce i uprawnieniach. Job Broker zapisuje pracę oraz dzierżawy. Policy Engine oblicza wymagane capability i approval. Approval Broker prowadzi decyzje człowieka osobnym kanałem. Registries dostarczają aktywne wersje agentów, narzędzi, modeli, kont i zasobów. Audit Ledger tworzy skorelowany zapis zdarzeń.

Execution Plane¶

Scheduler przydziela zasoby, ale nie nadaje uprawnień. Worker pobiera job pasujący do swoich możliwości. Tool Runner ponownie sprawdza politykę oraz jednorazowy grant, a następnie wywołuje dokładną wersję adaptera. Adapter wykonuje jeden zadeklarowany efekt: zapis kandydata, uruchomienie testu, render, odczyt kamery, draft wiadomości albo inne ograniczone działanie.

Dane i dowody¶

Durable state utrzymuje transakcyjne stany. Artifact Store przechowuje wersjonowane pliki oraz lineage. Memory Core dostarcza jawnie pochodzące rekordy kontekstu. Telemetria i receipty opisują faktyczne próby oraz obserwowane skutki. Żaden z tych magazynów nie jest bezpośrednio zapisywany przez model.

Przepływ danych i zaufania¶

Kierunek	Przenoszona treść	Kontrola
użytkownik → Core	intencja, plik, kanał, tożsamość	uwierzytelnienie, zakres projektu, klasyfikacja
Core → provider	minimalny context envelope	polityka danych, redakcja, budżet, zgoda zewnętrzna
provider → Broker	proposal envelope	ścisły schemat, oznaczenie jako niezaufane
Broker → worker	job, lease, grant, identyfikatory artefaktów	krótki TTL, zakres, powtórna walidacja
worker → adapter	typowany payload	exact tool version, dozwolone efekty, limity
adapter → Artifact Store	blob i metadane	hash, media type, skan, klasyfikacja, atomowy commit
adapter → Broker	receipt	schema, rozmiar, redakcja, korelacja
Broker → UI	zsanityzowany stan i dowody	role, projekt, klasyfikacja, brak sekretów

Płaszczyzny awarii¶

Architektura ma ograniczać promień awarii:

awaria UI nie zatrzymuje trwającego joba; po odświeżeniu stan pochodzi z brokera;
awaria providera powoduje zmianę wykonawcy albo kontrolowany błąd, ale nie omija polityki;
awaria workera wygasza lease; broker nie powtarza ślepo operacji nieidempotentnej;
awaria adaptera nie powinna uszkodzić brokera, ponieważ działa w procesie lub środowisku o zawężonych prawach;
awaria Artifact Store blokuje materializację i finalizację, ale nie usuwa historii joba;
awaria polityki lub approvala blokuje nowe skutki; odczyt istniejących raportów może pozostać dostępny;
utrata sieci między oddziałami nie unieważnia lokalnej prawdy; synchronizacja odbywa się po odzyskaniu łączności.

Granice instalacji¶

Najmniejsza instalacja może mieścić wszystkie role logiczne na jednej stacji, lecz nadal utrzymuje separację procesów, tożsamości i interfejsów. Większa instalacja rozdziela Management Node, GPU workery, storage, serwisy kamer i stanowiska aplikacyjne. Rozdzielenie sprzętowe nie zmienia kontraktów: lokalny worker i odległy worker realizują ten sam protokół lease/grant/receipt.

Zasada wymienialności¶

Każdy komponent wymienia się przez wersjonowany interfejs. Model Registry zna profile możliwości, nie „najlepszy model na zawsze”. Tool Registry wiąże tool_id@version z kontraktem, nie z przypadkowym skryptem. Workflow wskazuje role i wymagania, a nie konkretne GPU. Dane mają przenośne formaty i lineage. Dzięki temu produkt może ewoluować bez hurtowej migracji logiki biznesowej przy każdej zmianie dostawcy.

Scenariusz awaryjny całej architektury¶

W razie utraty spójności system zatrzymuje dispatch, utrwala dostępne logi, wykonuje kontrolowany checkpoint bazy, identyfikuje jobs w stanie running i oznacza efekty bez jednoznacznego receiptu jako uncertain. Operator przechodzi do Recovery Console z Management Node lub KVM-over-IP. Najpierw odtwarza Control Plane, następnie Artifact Store i dopiero potem workerów. Nie tworzy pustej bazy „żeby system wstał” ani nie kasuje niewygodnych lease; każda korekta powstaje jako jawne zdarzenie reconciliation.