Miary sukcesu¶

Zasada¶

Jedna liczba nie opisze NORBI. Metryki łączą wartość biznesową, jakość, bezpieczeństwo, operacje, prywatność i ekonomię. Model może być szybszy, ale jeśli zwiększa review albo ryzyko, nie jest sukcesem.

North-star¶

Zweryfikowane rezultaty zakończone w granicach polityki na jednostkę pełnego kosztu.

Rezultat liczy się tylko, gdy spełnia acceptance criteria, ma wymagane evidence/receipt i nie został później cofnięty jako błąd. Koszt obejmuje compute, providerów, review człowieka, support i amortyzację infrastruktury.

Produkt i użytkownik¶

Metryka	Definicja	Pułapka
task success	odsetek intencji zamkniętych zgodnie z kontraktem	nie liczyć samego `succeeded` bez walidacji
time-to-result	od intencji do accepted result	nie ukrywać waiting for human/data
human review time	aktywne minuty człowieka	liczba approvali nie wystarcza
rework rate	rezultaty wracające do poprawy	oddzielić zmianę zdania od błędu
adoption by workflow	użycie w kwalifikowanych przypadkach	DAU bez wartości jest mylące
explainability success	użytkownik rozumie dlaczego/źródła	badać zadaniowo, nie ankietą ogólną
accessibility completion	task completion z keyboard/mobile/screen reader	samo spełnienie statyczne nie wystarcza

Jakość agentów i modeli¶

hard-gate pass rate;
false positive/negative per domena;
structured output validity;
source/citation accuracy;
correct escalation i correct refusal;
hallucinated action/commitment rate;
model fallback success;
latency P50/P95/P99 per profil;
cost/energy per accepted result;
drift względem frozen evaluation set.

Metryki wiążą exact model, quantization, runtime, prompt/template, agent manifest i tool versions. Wynik globalny nie zastępuje profilu roli.

Execution Fabric i bezpieczeństwo¶

Twarde cele:

unauthorized effects = 0;
self-grant/self-approval/self-activation = 0;
grant double consume = 0;
agent raw shell paths = 0;
secret values in prompts/logs/artifacts = 0;
main write outside promotion tool = 0;
cross-project data leakage = 0.

Operacyjne: lease contention, uncertain-effect rate, reconciliation time, retry correctness, policy-deny categories, approval expiry/replay, adapter effect mismatch, audit completeness i time to revoke.

Operacje¶

availability per capability, nie tylko host uptime;
queue wait i deadline miss per priority;
worker utilization, preemption success i checkpoint recovery;
backup freshness, restore success, RPO/RTO achieved;
change failure rate, rollback/forward-fix success;
MTTA, MTTR i incident recurrence;
storage growth/quota breaches;
update adoption i stale versions;
KVM/WoL/UPS drill success.

Prywatność¶

liczba i wolumen external transmissions per class/provider;
odsetek zminimalizowanych/redagowanych pól;
data retention compliance i expired records backlog;
access review findings;
liczba projektów używających wyłącznie lokalnych providerów;
prompt/context size względem potrzebnego evidence;
opt-out i consent violations w komunikacji.

Biznes¶

deployment time-to-first-value;
udział components reused vs custom;
gross margin per SKU i partner;
annual recurring revenue oraz renewal;
support hours per installation/connector;
hardware/TCO variance vs plan;
liczba aktywnych płatnych workflow, nie tylko licencji;
partner-certified deployment success;
net revenue retention z rozszerzeń pakietów;
churn reason: brak wartości, koszt, jakość, trust lub zmiana strategii.

Progi autonomii¶

A1→A2: twarde testy 100%, stabilny result quality, approval disclosure zrozumiały. A2→A3: reprezentatywny shadow, niski exception/false action, idempotency/recovery, określony circuit breaker. A3→A4: end-to-end SLO, checkpoint, on-call, outcome metrics i udany drill. A5: dodatkowo brak cross-domain leakage, portfolio budget controls i federated outage tests.

Nie ustala się jednego procentu dla wszystkich domen. Próg błędu w generacji obrazka może być większy niż w płatności czy alarmie.

Dashboard właściciela¶

Miesięczny raport powinien zmieścić się na jednej stronie:

accepted results i zaoszczędzony czas;
review/rework i najczęstsze wyjątki;
safety/privacy: wszystkie naruszenia i external data;
availability/recovery/backup;
koszt compute/provider/support;
top 3 usprawnienia i top 3 ryzyka;
decyzje o autonomii, wersjach i pakietach.

Eksperymenty¶

Każde usprawnienie ma baseline, hipotezę, segment, horyzont, metrykę główną, guardrails i warunek stop. A/B test nie obejmuje niejawnie różnych uprawnień ani ludzi bez podstawy. Wynik negatywny jest zachowywany, aby system nie powtarzał tej samej nieskutecznej zmiany.

Scenariusz awaryjny metryk¶

Jeśli telemetria jest niepełna, dashboard pokazuje coverage i przerwę, nie interpolowany sukces. Brak audytu blokuje consequential operations. Metryki biznesowe mogą być odtworzone z receipts/artifacts, ale nie powinny mieszać okresów przed/po zmianie definicji. Każda definicja ma wersję i ownera.