Ekosystem i certyfikacja¶

Cel ekosystemu¶

Centralny zespół nie zbuduje i nie utrzyma wszystkich integracji, pakietów i konfiguracji sprzętu. Ekosystem ma umożliwić partnerom tworzenie wartości bez rozmywania granic bezpieczeństwa. Otwarte kontrakty i test kit obniżają barierę, a certyfikacja jasno odróżnia „działa u autora” od „spełnia określony profil jakości”.

Role¶

Core Maintainer — protokoły, security invariants, wydania platformy i root signing policy;
Publisher — plugin, agent lub pakiet branżowy; odpowiada za manifest i support;
Model Curator — provenance, benchmark i profil modelu;
Hardware Partner — konfiguracja, firmware, burn-in, recovery i lifecycle;
Implementation Partner — discovery, wdrożenie, konfiguracja, szkolenie i first-line support;
Independent Lab/Reviewer — powtarza testy i audytuje claims;
Customer Owner — zatwierdza aktywację w swoim środowisku; certyfikat nie zastępuje decyzji klienta.

Poziomy zaufania artefaktu¶

Status	Znaczenie
Unverified	znane pochodzenie, bez niezależnych testów; brak produkcyjnej aktywacji domyślnej
Verified Build	podpis, SBOM, reprodukowalny build i schema poprawne
Compatible	testy funkcjonalne z wersją platformy i profilem środowiska
Security Reviewed	threat model, adversarial/effect tests i brak otwartych wysokich problemów
Domain Certified	dodatkowe testy branżowe, dataset i reviewer domenowy
Critical Profile	recovery, HA, stress, incident i restrykcyjny support lifecycle

Status jest związany z exact wersją, platformą, konfiguracją i datą. Nie dziedziczy się automatycznie na kolejne wydanie.

Certyfikacja pluginu/narzędzia¶

1. Intake i tożsamość¶

Publisher, źródło, licencja, zakres, support, kontakt bezpieczeństwa i podpis. Pakiet bez jasnego właściciela nie uzyskuje wyższego statusu.

2. Supply chain¶

SBOM, zależności z checksum, reprodukowalny lub kontrolowany build, skan sekretów/licencji/malware, brak dynamicznego pobierania kodu. Hook instalacyjny nie aktywuje capabilities.

3. Contract tests¶

Strict input/output schema, unknown fields, limits, timeouts, cancellation, idempotency, receipts i stable errors. Narzędzie nie przyjmuje arbitrary shell/code/URL/path.

4. Effect containment¶

Obserwowany filesystem, process, network, account, UI i device effect mieści się w manifest. Testuje się path traversal, reparse, SSRF, redirects, credential leakage, replay, crash i concurrent invocation.

5. Integration i UX¶

Kompatybilność aplikacji/API, locale, accessibility, review disclosure, failure message i upgrade/downgrade. Desktop adapter testuje focus/modal/DPI. Physical adapter testuje simulator, interlock i safe state.

6. Review i signing¶

Niezależny reviewer ocenia evidence. Certyfikowany package dostaje podpis i wpis transparency catalog. Customer nadal instaluje i aktywuje przez własne approvals.

Certyfikacja modelu¶

Model package zawiera exact weights hash, format, tokenizer, prompt/template, quantization, runtime, license, source i hardware profile. Testy obejmują:

schema/structured output i tool proposal validity;
benchmarki dla ról, języków i długości kontekstu;
halucynacje źródeł, odmowę przy braku danych, prompt injection;
wyciek danych i cross-context behavior;
latency, throughput, VRAM/RAM, thermal/power;
cancellation, crash, deterministic seeds tam, gdzie wspierane;
degradację po quantization oraz różnice runtime;
safety domenowe bez mylenia filtra treści z capability security.

Wynik to karta profilu, nie globalny ranking. Model może być Certified for Fast Classification, ale nie for Legal Review. Model nie certyfikuje sam siebie; odpowiedzi oceniają deterministyczne metryki, niezależne modele i ludzie.

Certyfikacja sprzętu¶

Konfiguracja obejmuje exact motherboard/BIOS, CPU, RAM, GPU/VBIOS/driver, storage/firmware, NIC, PSU, cooling, UPS, KVM i OS image. Testy:

burn-in CPU/RAM/GPU i thermal soak;
SMART/endurance, filesystem, WAL/power-loss i restore;
transient/power budget, UPS runtime, graceful shutdown;
WoL, sleep/wake, ATX/KVM i cold boot;
model/app benchmarks i multi-job interference;
network segmentation, device identity i firmware lifecycle;
wymiana komponentu, backup restore i recovery drill.

Certyfikat podaje workload envelope i hałas/energię, nie tylko „kompatybilne”. Zmiana firmware może wymagać recertyfikacji profilu krytycznego.

Certyfikacja partnera¶

Partner zdaje szkolenie z architektury, twardych granic, deployment protocol, data classification, recovery i incident response. Dostarcza dwa nadzorowane wdrożenia i przechodzi audit jakości. Uprawnienie jest czasowe; wymaga ciągłego szkolenia i niskiego poziomu naruszeń. Partner nie może reklamować własnego pluginu jako certyfikowanego bez lab review.

Marketplace¶

Listing pokazuje publisher, status, exact version, capabilities/effects, accounts/network, data practices, licencję, cenę, support, known limitations, compatible profiles i datę review. Zakup tworzy entitlement, nie installation/activation. Security advisory może automatycznie zawęzić routing lub oznaczyć wersję revoked, ale nie instaluje naprawy bez polityki.

flowchart LR
    P["Publisher candidate"] --> B["Build + SBOM"]
    B --> T["Contract/effect/security tests"]
    T --> D["Domain tests"]
    D --> R["Independent review"]
    R --> S["Signing + catalog"]
    S --> C["Customer install approval"]
    C --> A["Customer activation approval"]
    A --> M["Monitoring + recertification"]

Vulnerability response¶

Publisher ma kanał zgłoszeń, severity, embargo i czas naprawy. Advisory wskazuje versions, effects, workarounds i revocation recommendation. Registry może fail closed dla wersji krytycznie złośliwej. Klient zachowuje audit i artifacts. Nowa wersja przechodzi skrócony lub pełny proces zależnie od zmiany; emergency nie znaczy bez testów.

Strategia rozwoju¶

Najpierw SDK, schema, test harness i trzy wzorcowe adaptery wysokiej jakości.
Następnie dwa pakiety branżowe z partnerami i wspólnymi components.
Potem marketplace curated, nie otwarty bez kontroli.
Rozdzielenie lab/review od sprzedaży premium, aby zmniejszyć konflikt interesów.
Transparency catalog, publiczne security advisories i wersjonowane compatibility matrices.

Ryzyka i scenariusz awaryjny¶

Ryzyka: pay-to-certify, fałszywe znaki, stale certification, supply-chain compromise i zależność od jednego laba. Ograniczenia: publiczne kryteria, evidence hashes, okres ważności, losowe audyty, odwołania i możliwość niezależnej reprodukcji.

Przy kompromitacji klucza signing wydawca revoke key, katalog publikuje incident, Tool Registry blokuje dotknięte pakiety i wymaga ponownego podpisu z nowym trust root. Klient nie usuwa historycznych podpisów; chain zachowuje informację, że były ważne w czasie wykonania.