Definicja produktu¶
Czym NORBI jest¶
NORBI jest prywatnym, lokal-first i modułowym systemem agentowym. Jego zadaniem jest koordynowanie modeli, agentów, narzędzi, procesów, aplikacji oraz ludzi w celu osiągnięcia sprawdzalnego rezultatu. System może działać na jednym komputerze, w lokalnej sieci z kilkoma workerami albo w instalacji wielooddziałowej. Telefon i przeglądarka służą jako Control Plane; wykonanie odbywa się wyłącznie na zapisanych, uwierzytelnionych workerach.
Podstawową jednostką wartości nie jest wiadomość na czacie, lecz zamknięty rezultat: dokument, decyzja, harmonogram, render, poprawka kodu, raport, przygotowana rozmowa, zaktualizowany rekord albo sterowanie urządzeniem — z właściwym poziomem zatwierdzenia i dowodami.
Czym NORBI nie jest¶
NORBI nie jest:
- pojedynczym chatbotem połączonym z terminalem;
- modelem językowym o stałej nazwie;
- zdalnym pulpitem ukrywającym ręczne klikanie;
- aplikacją, która traktuje wygenerowany tekst jako prawdę;
- usługą chmurową wymagającą wysyłania danych klienta;
- systemem, w którym jedno „potwierdzam” daje nieograniczone uprawnienia;
- autonomicznym administratorem mogącym aktywować własny kod, narzędzia lub konta.
Granice odpowiedzialności¶
NORBI odpowiada za prawidłowe przeprowadzenie zaakceptowanego procesu w granicach danych i narzędzi, którymi dysponuje. Właściciel wdrożenia odpowiada za decyzje biznesowe, legalność przetwarzania, konfigurację ról oraz zatwierdzenie operacji, których skutków system nie może sam wiarygodnie ocenić. Dostawca pakietu lub adaptera odpowiada za deklarowany kontrakt, testy i aktualizacje bezpieczeństwa. Model AI pozostaje niedeterministycznym dostawcą propozycji, a nie podmiotem uprawnionym.
Model obiektów produktu¶
| Obiekt | Rola | Trwała tożsamość |
|---|---|---|
| Project | granica kontekstu, danych, polityk i uczestników | project_id |
| Job | najmniejsza dzierżawiona jednostka jednego efektu lub transformacji | job_id |
| Workflow | wersjonowany graf zależności wielu jobs | workflow_definition_id, workflow_run_id |
| Agent | manifest roli, instrukcji, narzędzi i limitów | agent_id@version |
| Tool | typowany adapter wywołujący określony efekt | tool_id@version |
| Provider | adapter modelu lokalnego lub zewnętrznego | provider_id@version |
| Artifact | niezmienny rezultat lub wejście z linią pochodzenia | artifact_id@version, hash |
| Memory record | twierdzenie lub zdarzenie z zakresem i źródłem | memory_id@version |
| Approval | decyzja człowieka związana z konkretnym kontekstem | approval_request_id |
| Grant | jednorazowe, krótkie prawo wykonania zatwierdzonego efektu | grant_id, nonce, expiry |
| Execution receipt | dowód próby i obserwowanego skutku | receipt_id |
| Account | niejawny rekord tożsamości bez sekretu | account_id |
| Resource reservation | czasowy przydział zasobu, nie uprawnienie | reservation_id |
Karta całego produktu¶
| Pole | Definicja |
|---|---|
| Cel | Zmniejszać koszt koordynacji i wykonywania złożonej pracy bez utraty prywatności, kontroli i możliwości audytu. |
| Odpowiedzialności | Rozpoznanie zamiaru; plan; dobór wykonawców; polityka; approval; wykonanie; walidacja; prezentacja; historia. |
| Wejścia | Polecenia, dokumenty, zdarzenia, sensory, rekordy biznesowe, stan aplikacji, polityki i pamięć. |
| Wyjścia | Artefakty, komunikaty, zmiany stanu, receipty, raporty walidacji, eskalacje i decyzje. |
| Zależności | Lokalny Control Plane, rejestry, baza transakcyjna, Artifact Store, workerzy i jawnie skonfigurowane adaptery. |
| Kontrakty | Ścisłe schematy, wersje, hashe, idempotency, klasy danych, capability, approval policy, limity i kryteria akceptacji. |
| Uprawnienia | Domyślnie brak; zakres wynika z aktywnych przypisań właściciela i polityki. |
| Autonomia | Per workflow i per efekt; od sugestii do nadzorowanego działania, bez samodzielnej eskalacji. |
| Walidacja | Techniczna, semantyczna, domenowa i ludzka, zależnie od ryzyka. |
| Scenariusz awaryjny | Zatrzymanie wykonania, zachowanie dowodów, oznaczenie niepewności, przejście do trybu odzyskiwania i ręcznej decyzji. |
Pełny przebieg działania¶
- Rejestracja intencji. System zapisuje oryginalną prośbę, kanał, autora, projekt i klasyfikację danych. Treść zewnętrzna jest oznaczona jako niezaufana.
- Doprecyzowanie rezultatu. Norbi ustala oczekiwany artefakt, termin, budżet, kryteria jakości oraz działania, których nie wolno wykonywać.
- Plan. Planner tworzy DAG. Każdy węzeł ma wykonawcę, kontrakt wejścia/wyjścia, timeout, retry policy, potrzebny zasób i walidator.
- Ocena polityki. System wylicza capability, ryzyko, potrzebę approvala i dozwoloną lokalizację wykonania. Dane nieznane powodują odmowę, nie optymistyczne założenie.
- Wykonanie. Worker dzierżawi jeden job, pobiera jednorazowy grant, wywołuje dokładną wersję adaptera i raportuje obserwowany skutek.
- Walidacja. Osobne narzędzia lub agent-oceniający sprawdzają wynik względem kryteriów. Ten sam agent nie może sam potwierdzić zmiany swoich uprawnień ani aktywacji.
- Przegląd. Człowiek otrzymuje treść, skutki, różnice, ryzyka i dowody. Zatwierdzenie artefaktu nie publikuje go automatycznie.
- Finalizacja. Osobna operacja wdraża, wysyła lub publikuje wynik, jeśli tego wymaga cel i istnieje właściwa zgoda.
- Uczenie operacyjne. System może zaproponować zmianę workflow, pamięci lub polityki na podstawie błędów. Propozycja przechodzi taką samą ścieżkę jak każda zmiana.
Kryterium ukończenia¶
Zadanie nie jest ukończone, gdy model napisał „gotowe”. Stan succeeded wymaga poprawnego wyniku adaptera i wymaganej walidacji. Stan closed wymaga zrealizowania kontraktu rezultatów albo udokumentowanego, zaakceptowanego wyjątku. Jeżeli skutek zewnętrzny jest niepewny — na przykład połączenie sieciowe przerwano po wysłaniu żądania — job przechodzi do uncertain, a nie do automatycznego retry.