Artefakty, pamięć i zasoby¶
Artifact Store¶
Artifact Store jest kanoniczną granicą dla plików i wyników. Oddziela dane runtime od kodu, utrzymuje pochodzenie i eliminuje zaufanie do zmiennej ścieżki typu final_v7_poprawiony.docx.
| Pole | Kontrakt |
|---|---|
| Cel | przechować niezmienne blob-y, wersje, lineage, klasyfikację i cykl review/publikacji. |
| Wejścia | strumień danych, media type, parent IDs, creator, parametry transformacji, retencja. |
| Wyjścia | artifact ID/version, SHA-256, metadata, materialization lease, preview. |
| Zależności | storage lokalny, broker-owned metadata DB, skanery i walidatory formatów. |
| Uprawnienia | artifact-scoped read/write; publikacja i usunięcie są oddzielnymi capabilities. |
| Autonomia | tworzenie candidate/preview; brak automatycznego przejścia do published. |
| Walidacja | hash, typ, rozmiar, struktura, malware policy, lineage i konsystencja metadata. |
| Awaria | atomowy zapis temp→hash→rename; quarantine; odbudowa indeksu z manifestów i backupu. |
Cykl ma niezależny artifact_stage: input, candidate, preview, approved, published oraz artifact_status: available, quarantined, rejected, expired, deleted. Approved nie znaczy published. Edycja tworzy nową wersję z rodzicem; mutable label latest nigdy nie jest częścią approvala.
Materialization udostępnia aplikacji tymczasową kopię na czas lease. Zamknięcie sesji usuwa kopię, nie blob. Duże media mogą być chunkowane; manifest wiąże hashe części. Sekrety są domyślnie odrzucane, bo nie powinny stać się zwykłym artefaktem.
Memory Core¶
Pamięć przechowuje użyteczne twierdzenia i zdarzenia, nie surowy „wszystko-log”. Rekord ma treść, typ, źródło, projekt, podmiot, klasyfikację, confidence, valid-from/to, retention, allowed consumers oraz historię korekt.
Rodzaje pamięci obejmują epizodyczną, semantyczną, proceduralną, preferencje, operacyjną i negatywną. Retrieval zwraca nie tylko tekst, lecz także pochodzenie. Konfliktujące rekordy są widoczne. Treść z kanału zewnętrznego nie może zastąpić polityki.
| Pole | Kontrakt |
|---|---|
| Wejścia | candidate memory record, źródło, scope, confidence, expiry, evidence. |
| Wyjścia | zrankowane rekordy z provenance i powodem wyboru. |
| Zależności | indeks tekstowy/wektorowy, metadata DB, polityka retencji, Artifact Store. |
| Uprawnienia | rozdzielone read/write/approve/delete per projekt i klasa. |
| Autonomia | może proponować pamięć; wysokozaufana pamięć proceduralna wymaga review. |
| Walidacja | źródło, konflikt, aktualność, zakres, poisoning checks i test retrieval. |
| Awaria | brak pamięci degraduje personalizację, ale nie omija polityki; odbudowa indeksu z rekordów. |
Resource Scheduler¶
Scheduler zarządza CPU, GPU, VRAM, RAM, przestrzenią dyskową, licencjami aplikacji, kamerami, czasem człowieka i oknami maintenance. Przydział zasobu nie jest capability ani approvalem.
| Pole | Kontrakt |
|---|---|
| Wejścia | resource request, priority, deadline, estimate, preemption/checkpoint class. |
| Wyjścia | reservation/grant/release, kolejka, odmowa lub alternatywa. |
| Zależności | worker advertisements, telemetry, quota, licencje i policy budgets. |
| Uprawnienia | może rezerwować zasób; nie może wykonać narzędzia. |
| Autonomia | optymalizacja kolejki w granicach SLA i budżetu energii. |
| Walidacja | pojemność, ekskluzywność, fairness, deadline i brak oversubscription. |
| Awaria | wygaśnięcie rezerwacji, bezpieczne zwolnienie, ponowne rozpoznanie zasobów. |
Przykład: vision alarm ma wyższy priorytet niż render nocny. Jeśli renderer wspiera checkpoint, Scheduler prosi workflow o pause, czeka na zweryfikowany artefakt checkpointu, zwalnia GPU i uruchamia analizę. Nie odbiera GPU procesowi przez brutalne zabicie, jeżeli mogłoby to uszkodzić projekt.
Accounts Registry i credential boundary¶
Rejestr kont zna platformę, nazwę, właściciela, dozwolone narzędzia, akcje, odbiorców, klasy danych, status i uchwyt sejfu. Nie zawiera haseł, tokenów, cookies ani kluczy. Adapter prosi o krótkotrwałą sesję dla konkretnego account/action/destination. Broker sprawdza scope i approval, credential broker tworzy uchwyt procesowy, a po wykonaniu go unieważnia.
Przykładowe polecenie i przebieg¶
„Na podstawie ostatnich trzech zatwierdzonych ofert przygotuj nową dla klienta X”. Context Builder pobiera tylko approved artifacts z właściwego projektu oraz pamięć o kliencie o aktywnej ważności. Generator tworzy candidate DOCX. Validator sprawdza szablon, dane firmy, sumy i brak przypadkowych danych innych klientów. Artifact Store zapisuje wersję i lineage. Account Registry nie jest potrzebny, dopóki użytkownik nie poprosi o wysłanie; wtedy osobny job wiąże konkretne konto, odbiorcę, plik i treść.
Ryzyka i scenariusz awaryjny¶
Największe ryzyka to poisoning pamięci, błędna klasyfikacja danych, wyciek przez preview, brak miejsca i pomylenie wersji. Ograniczenia obejmują content hashes, quarantine, quota, retention hold, testy cross-project isolation i jasne etapy. Przy braku miejsca nowe artefakty są blokowane przed rozpoczęciem kosztownego zadania. Garbage collection usuwa tylko obiekty jawnie kwalifikowane, z tombstone i bez aktywnego hold; nigdy w reakcji na swobodną instrukcję modelu.