Terminologia¶
Krótki, alfabetyczny słownik pojęć, których Secruna używa w produkcie, dokumentacji i rozmowach. Te same terminy pojawiają się w schemacie API i w logu audytu, więc spójne słownictwo ma znaczenie.
AI system (system AI)¶
Wyodrębniony fragment oprogramowania, którego zachowanie zależy od modelu — klasyfikator, generatywny endpoint LLM, system rekomendacji, zautomatyzowana ścieżka decyzyjna albo cokolwiek, co recenzent EU AI Act, RICS lub UK Defence AI Playbook nazwałby AI. Systemy AI żyją wewnątrz tenanta i akumulują artefakty, gdy je odkrywamy i analizujemy.
Artifact (artefakt)¶
Pojedynczy dowód dotyczący systemu AI — rola IAM przy funkcji Lambda, fragment kodu źródłowego z repozytorium, wartość konfiguracyjna, wyekstrahowane oświadczenie o przeznaczeniu albo fragment karty modelu. Artefakty są tym, na czym rule entries (wpisy reguł) wykonują ewaluację.
Audit log entry (wpis w logu audytu)¶
Niezmienny wiersz zapisujący akcję wykonaną w platformie — kto, co, kiedy, plus łańcuch hashów uniemożliwiający cichą edycję. Każda mutacja widoczna dla klienta produkuje co najmniej jeden wpis.
Connector (konektor)¶
Komponent, który zaciąga dane z systemu klienta do Secruny — AWS, Azure, GCP, GitHub, wewnętrzne narzędzia HR, narzędzia specyficzne dla rzeczoznawstwa pod pakietem RICS. Konektory działają wewnątrz discovery worker i emitują artefakty.
Discovery run (przebieg wykrywania)¶
Pojedyncze wykonanie discovery workera dla tenanta. Przebieg skanuje skonfigurowane konektory, zapisuje nowe artefakty, re-ewaluuje reguły i emituje webhooki. Przebiegi są wyzwalane przez cron (co dwie minuty) oraz przez zdarzenia (Plan 61 Phase 2).
Evidence pack (pakiet dowodowy)¶
Pakiet artefaktów plus verdict copy dla regulatora albo audytora — dokumentacja techniczna EU AI Act Annex IV, AI Use Disclosure Statement RICS, CSV z Firm AI Register. Evidence packs to namacalny output z przeglądu compliance.
Framework¶
Reżim regulacyjny, który Secruna wspiera jako produkt. Dziś: EU AI Act, RICS, UK Defence AI Playbook, Defence Standard 05-138, Secure by Design. Każdy framework ma własny rule book, taksonomię i powierzchnie zwrócone do klienta.
Org admin / reviewer / viewer¶
Trzy poziomy ról na tenancie. Org admin może zmieniać ustawienia, zapraszać członków i edytować werdykty. Reviewer może edytować werdykty, ale nie może zmieniać ustawień tenanta. Viewer jest read-only — przydatny dla prawników lub zewnętrznych audytorów.
Rule book / rule entry / matcher¶
Rule book to korpus YAML ładowany przy starcie przez
multi-framework loader. Rule entry to pojedynczy wiersz —
tytuł, framework, kategoria, matcher, opis zwrócony do klienta.
Matcher to ustrukturyzowane zapytanie (zwykle nad
artifact_metadata), które decyduje, czy artefakt wyzwala regułę.
Subscription (subskrypcja)¶
Rekord Plan 103 na tenancie mówiący, które frameworki zostały zakupione. Wybór frameworka w onboardingu czyta z tego rekordu; loader reguł filtruje po nim; panel ukrywa powierzchnie, których tenant nie subskrybuje.
Tenant (najemca)¶
Jedna organizacja klienta. Tenanty są izolowane od siebie na
poziomie wiersza bazy danych przez PostgreSQL row-level security
oraz zmienną sesyjną app.current_tenant_path (typ ltree). Nie
istnieje współdzielona pamięć pomiędzy tenantami.
TEVV¶
Test, Evaluation, Verification i Validation. Kategoria w UK Defence AI Playbook dla systemów AI, które wymagają dowodu osiągów wobec zdefiniowanego progu przed wdrożeniem. Reguły w pakiecie Defence kierują systemy oznaczone jako TEVV do jawnej kolejki przeglądu.
Verdict / verdict copy (werdykt / treść werdyktu)¶
Verdict to ocena platformy, czy system AI spełnia regułę — pass, fail, needs-review albo not-applicable. Verdict copy to ludzkie wyjaśnienie, które Secruna pisze obok: czego reguła wymaga, co znaleźliśmy i co klient musi zrobić dalej. Verdict copy ląduje w evidence packs.