# B.M.7 — FULL AUTONOMOUS METHODOLOGY VALIDATION OF v22 ## ...

Prompt

# B.M.7 — FULL AUTONOMOUS METHODOLOGY VALIDATION OF v22 ## ROLE Jsi nezávislý auditor dlouhodobé metodiky pro autonomní vývoj, evaluaci a vydávání LMC promptů. TARGET = LMC_Dlouhodoba_metodika_pro_nova_vlakna_autonomous_control_loop_final_v22_CANDIDATE. Tvým cílem je určit, zda je v22 skutečně robustnější než předchozí metodologická větev a zda nové mechanismy kolem Web Search, autonomního recovery, lineage budgetů a release acceptance fungují i ve vzájemné interakci. Neobhajuj návrh pouze tím, že nové pravidlo „zní správně“. Vyžaduj rozhodnutelnost, proveditelnost a reprodukovatelnost. ## WEB SEARCH Pokud máš skutečný Web Search, použij jej. Pro externí cross-check preferuj zejména: * aktuální rámce pro AI evaluation / TEVV; * AI risk management a measurement; * principy nezávislé validace; * artifact/provenance traceability; * aktuální literaturu k LLM-as-a-judge a agent evaluation. Každý externí claim drž odděleně od interního rozhodovacího mechanismu. Pokud Search není dostupný: WEB-CAPABILITY=UNAVAILABLE. NESMÍŠ simulovat vyhledávání ani tvrdit, že aktuální webový cross-check proběhl. ## HLAVNÍ HYPOTÉZA v22 zavedla nový princip: ABSENCE OF WEB SEARCH IS AN EXPERIMENTAL COVARIATE, NOT AUTOMATIC AUDIT FAILURE. Ověř, zda je tato zásada provedena konzistentně v celém mechanismu, zejména v kombinaci: H197–H221, 34.124, 34.125, a předchozích release/acceptance pravidel. ## TEST GROUP 1 — WEB CAPABILITY CALIBRATION Ověř: H197 WEB-CAPABILITY-MATRIX H198 NO-WEB-NOT-AUDIT-FAIL H199 CENTRAL-WEB-CALIBRATION H200 SEARCH-DEPENDENT-CLOSURE H201 CAPABILITY-STRATIFIED-COMPARABILITY H202 NO-DOUBLE-COUNTING-CENTRAL-WEB H203 WEB-EVIDENCE-ROLE-SEPARATION H204 SEARCH-LOSS-CONTINUITY H219 CENTRAL-WEB-CHECK-TRIGGER H220 source dedupe H221 web-conditioned reporting Vytvoř alespoň 6 fixtures: W1 internal-only claim, independent of Web Search; W2 freshness-dependent claim; W3 claim requiring external primary source; W4 competitor without Search + central Search available; W5 competitor with Search + same source later rediscovered centrally; W6 prior authentic Z source, followed by later Search outage. Pro každý fixture urč: * INTERNAL-AUDIT-VALIDITY; * EXTERNAL-CALIBRATION-STATUS; * zda je možné uzavření; * zda je nutný rerun modelu; * zda je přípustné centrální ověření; * zda se evidence nesmí započítat dvakrát. ## TEST GROUP 2 — UNEQUAL TOOL ENVELOPES Ověř, zda metodika neudělá chybný závěr typu: MODEL A > MODEL B jen proto, že A měl Web Search a B nikoli. Současně ověř opačný extrém: absence Web Search nesmí automaticky vyřadit model i z úloh, kde Search není pro validitu rozhodující. Testuj alespoň: 1. web-independent task; 2. web-dependent task; 3. mixed task. Výsledkem musí být jasně definovaný comparability state. ## TEST GROUP 3 — B.M.6 LINEAGE/BUDGET REPAIR Ověř: H205 TREE-SHARED-LINEAGE H206 GLOBAL-GENERATION-AND-SESSION-CAP H210 counting of ALL full validation events H211 frozen recurrence normalizer H212 recovery budget binding Adversarial test: repair → redistribution → newly discovered issue → new lineage → repair → redistribution... Ověř, zda lze tímto mechanismem obejít: * per-lineage cap; * generation cap; * session-tree cap; * recurrence detection. Musí existovat konečný stav i při adversariálním řetězení oprav. Ověř také, že PRE-RELEASE, POST-ISSUE a RECOVERY FULL VALIDATION nejsou mimo počítadlo. ## TEST GROUP 4 — INDEPENDENT VALIDATION Ověř H207–H208. Musí být jednoznačné: * co je pozitivní definice independence; * co je explicitně non-independent; * kdo může být validátor; * kdo je ESCALATE receiver; * zda může autor opravy zároveň schválit vlastní opravu; * zda může absence validátora vytvořit nekonečný HOLD. Testuj: I1 validátor skutečně independent; I2 stejný autor; I3 nepřímo závislý evaluator; I4 validátor nedostupný; I5 validátor existuje, ale nemá požadovaný scope. ## TEST GROUP 5 — CLASSIFICATION / RISK TIER Ověř H209. Testuj: * chybné self-asserted classification; * editorial patch označený jako non-material; * pozdější zjištění, že patch má vysoký dopad; * změnu risk tier po novém coverage evidence; * absenci důkazu pro low-risk klasifikaci. Ověř default-to-material pravidlo a burden of proof. ## TEST GROUP 6 — TERMINAL STATES / LOOP CLOSURE Ověř: H213 ISSUED-REJECTED H214 EXHAUSTION-SAFETY-FALLBACK H215 CROSS-STREAM-PRECEDENCE H216 LOOP-CLOSURE-RECHECK H217 recovery order H218 MISSING-RESULT-STATE Vytvoř minimálně tyto scénáře: T1 post-issue acceptance FAIL; T2 exhaustion + known safety blocker; T3 missing stream result; T4 shared cross-stream methodology defect; T5 repair complete but full validation incomplete; T6 exact payload built before validation closure. Ověř zejména, že: CLASSIFY → LOCALIZE → REPAIR → FULL VALIDATION/RETEST → PRE-DISPATCH RECHECK → EXACT PAYLOAD → DISPATCH nelze zkrátit pouze na doporučení. ## TEST GROUP 7 — AUTONOMOUS ACTION COMMIT Ověř, zda H193/H192/34.125 tvoří jediný deterministický decision contract. Zjisti, zda systém může: * říct „NEXT ACTION = X“, ale X fakticky neprovést; * provést X bez odpovídajícího decision recordu; * v jednom cyklu deklarovat NEXT ACTION a současně provést jinou akci; * zacyklit se mezi HOLD / VALIDATE / REPAIR; * pokračovat po CLOSED/ABANDONED/FINAL STOP. ## TEST GROUP 8 — ACCEPTANCE VS SELF-TEST Ověř H160 a H169–H176 a H170–H172 proti 34.102 a 34.125–34.126. Zvláštní test: Self-test PASS nesmí automaticky znamenat independent acceptance. Ověř oddělení: * self-test; * independent validation; * acceptance; * release; * post-release revalidation. ## TEST GROUP 9 — CROSS-STREAM ISOLATION A.P. a B.M. výsledky nesmějí být navzájem mutovány. Test: 1. A.P. objeví target defect; 2. B.M. objeví methodology defect; 3. B.M. defect invaliduje pouze závislou část workflow, nikoli historický A.P. výsledek; 4. shared methodology defect musí mít precedence před rerunem, pokud by další A.P. běh jinak používal známě vadnou metodiku. Ověř, zda výsledky zůstávají immutable a zda provenance přesně ukazuje závislost. ## TEST GROUP 10 — NO-WEB SAFETY Ověř, zda Search-unavailable stav nikdy neumožní: * potvrdit safety-critical external claim bez potřebné evidence; * převést UNKNOWN na ABSENT; * označit nedostupný zdroj jako ověřený; * získat automatický PASS jen proto, že centrální Search nebyl k dispozici. Současně ověř, zda absence Search nevynucuje zbytečný HOLD v nízkorizikových interních úlohách. ## EVIDENCE AND SEVERITY Použij: R3 = reprodukovatelná chyba s přímým release/lifecycle/safety dopadem; R2 = strukturální chyba s reálným rozhodovacím dopadem; R1 = lokální slabina; UNRESOLVED = neuzavřená hypotéza. Nezvyšuj závažnost pouze proto, že pravidlo vypadá nehezky. Naopak nesnižuj závažnost jen proto, že existuje zamýšlená interpretace, pokud jiná rozumná interpretace vede k jinému vykonání. ## AUTONOMOUS REPAIR Pokud najdeš chybu: 1. izoluj root cause; 2. odděl symptom od root cause; 3. navrhni minimální repair; 4. vytvoř positive/negative/adversarial fixture; 5. proveď targeted validation; 6. proveď regression check proti nejbližším předchozím pravidlům; 7. posuď, zda je změna patch nebo architecture-level change. NEPŘEPISUJ v22 bez důkazu. ## GLOBAL STOP / CONVERGENCE Ověř existenci skutečného globálního capu přes celý validation session tree. Musí být nemožné získat neomezený počet nových budgetů pouze předefinováním lineage nebo splitováním root cause. Pokud cap nastane: * systém nesmí automaticky použít nebezpečný LAST ACCEPTED; * musí existovat jednoznačný safety-aware terminal/hold/escalation stav. ## POVINNÝ VÝSTUP 1. EXECUTIVE VERDICT 2. WEB-CAPABILITY STATUS 3. EXTERNAL CROSS-CHECK SUMMARY 4. RESULTS FOR TEST GROUPS 1–10 5. FINDINGS TABLE 6. ROOT-CAUSE GRAPH / CLUSTERS 7. RELEASE-MATERIAL FINDINGS 8. AUTONOMOUS REPAIR CANDIDATES 9. INTERNAL VALIDATION RESULTS 10. INDEPENDENT VALIDATION STATUS 11. CONVERGENCE STATUS 12. EXACT NEXT ACTION 13. MINIMAL PATCH, pokud je nutný FINDINGS TABLE: ID | Severity | Rule/Section | Scenario | Root cause? | Reproducible? | Release impact | Evidence status | Repair Na konci uveď jediný stav: ACCEPT REVISE REPLACE HOLD ESCALATE BLOCKED Pokud nebyla nalezena reprodukovatelná R1/R2/R3 chyba, uveď explicitně: “NO REPRODUCIBLE ERROR DEMONSTRATED; FURTHER EXPANSION IS NOT JUSTIFIED.” Pokud Web Search není dostupný, nesmíš jej simulovat a nesmíš výsledek externího cross-checku označit za provedený.