Шари результату аудиту
Аудит Aiscovery починається з реальної цілі користувача, а не із суми checklist. Результат поєднує п'ять шарів: scenario contract, один або кілька agent runs, deterministic assertions, evidence artifacts та actionable finding.
Task matrix є найкращою точкою старту. Вона показує, чи кожен required agent profile досяг очікуваного final state. Technical checks пояснюють умови, які могли допомогти або завадити цьому результату. Успішний technical check не замінює виконану задачу.
Результат корисний лише тоді, коли він пов'язаний з observed run. Scores узагальнюють аудит, але recordings, traces та assertions пояснюють його.
Кожен finding має відповідати на чотири питання:
- Якої user goal торкнулася проблема?
- Що відбулося замість очікуваного результату?
- Яке evidence доводить різницю?
- Яка зміна та acceptance criterion закриють finding?
Статуси tasks і checks
Checks і task runs мають різні набори статусів, бо відповідають на різні питання. Check оцінює конкретну умову. Task оцінює, чи агент досяг бізнес-цілі.
| Record | Status | Значення |
|---|---|---|
| Check | pass | Критерій пройдено з валідним evidence. |
| Check | partial | Критерій виконано частково, а вплив можна спостерігати. |
| Check | fail | Спостерігається fail criterion. |
| Check | blocked | Check розпочато, але site access не дав його завершити. |
| Check | not_applicable | Check не належить до погодженого scope. |
| Check | not_run | Check заплановано, але не виконано. Confidence зменшується. |
| Task | success | Усі positive і negative assertions пройдено. |
| Task | success_with_friction | Final state правильний, але run перевищив budget кроків, retries або interventions. |
| Task | partial | Частину цілі виконано, але важливий assertion не пройдено. |
| Task | failed | Цілі не досягнуто або фінальний результат неправильний. |
| Task | blocked_by_site | Сайт заблокував in-scope flow. |
| Task | blocked_by_agent_policy | Policy виконавця не дозволила виконати in-scope goal. |
| Task | inconclusive | Fixture, evaluator або requirement не дали зробити висновок. |
not_run та inconclusive не рахуються приховано як failures. Їх виключають із readiness calculation і вони знижують confidence, тому неповний аудит не виглядає більш певним, ніж є насправді.
Attribution провалів
Однаковий видимий провал може мати різні причини. Attribution завершується перед scoring і розділяє чотири основні класи:
- Website failure: deterministic baseline або кілька спроможних агентів відтворюють дефект сайту.
- Agent-specific failure: сайт працює у baseline та для інших profiles, але один profile не завершує задачу.
- Policy block: agent product відмовляється від дії або потребує handoff через власну policy boundary.
- Infrastructure failure: runner, fixture, network або evaluator провалилися незалежно від сайту й capability агента.
Policy block отримує нуль для відповідного agent profile, бо користувач цього продукту не може завершити задачу. Він не стає website defect без додаткового evidence. У report обидва твердження залишаються видимими.
Severity і blockers
Severity описує вплив, а не очікувану складність виправлення.
| Severity | Інтерпретація |
|---|---|
P0 | Ризик грошей, sensitive data, cross-tenant access, duplicate action або повний blocker critical transaction. |
P1 | Системний провал primary task або суттєво неправильна інформація без P0 impact. |
P2 | Відчутне тертя, нестабільність або дефект secondary flow. |
P3 | Незначна прогалина або можливість покращення. |
Unresolved applicable P0 обмежує фінальний readiness result до 39. Unresolved P1 обмежує його до 59. Raw score залишається видимим поруч із capped score, причиною та linked finding.
Обмеження та безпечна інтерпретація
Результати аудиту є versioned observations із визначеного environment. Вони не гарантують однакової поведінки кожної поточної або майбутньої моделі.
Перед порівнянням двох результатів перевірте:
- environment сайту та версію fixture;
- agent product, model, tools і policy restrictions;
- viewport, locale, cookies та authentication state;
- planned і completed repetitions;
- unsupported capture capabilities або redacted evidence;
- production stop gates і дії, які навмисно не завершувалися.
Production payments, bookings, submissions, deletions та інші незворотні операції зупиняються перед commit. Твердження про повне завершення потребує approved sandbox або іншого reversible environment із independently verified final-state assertions.