nsaspy/prolog-rlm

Fork 0

[EPIC][expert] Repair / diagnosis expert: failure hypotheses, evidence gaps, bounded repair, and no-progress detection #413

New issue

Open

opened 2026-09-08 01:29:21 +00:00 by nsaspy · 5 comments

nsaspy commented

2026-09-08 01:29:21 +00:00

Owner

Parent: #376
Depends on: #377, #384
Integrates with: #379, #380, #381, #382, #383
Research input: #397 #401A

Goal

Add a Repair / Diagnosis Expert that consumes structured VERIFY failures/unknowns/blocked states, performs explicit bounded diagnosis where ambiguity matters, and derives the smallest defensible next repair or evidence-acquisition subgoal without weakening the Frozen Spec.

This expert is the core of the closed-loop retry path:

VERIFY not satisfied / unexpected observation
  -> classify failure/gap
  -> construct diagnostic conflict(s) where model/evidence permits
  -> derive competing hypotheses
  -> gather discriminating evidence if needed
  -> choose repair strategy only when sufficiently justified by policy
  -> return typed repair subgoal(s)
  -> Planner integrates an admitted procedural method/network
  -> execute
  -> re-observe
  -> VERIFY again

It does not directly declare success and does not own the scheduler.

MACHINE-SPIRIT #401A refinement — diagnosis is not repair selection

Depth 4A adopts the model-based diagnosis lesson from Reiter/de Kleer-style systems: candidate explanation and corrective action are distinct reasoning products.

Preserve explicit diagnostic state equivalent to:

diagnostic problem id
expected behavioral/causal model ref
current observation refs
conflict set(s)
candidate hypotheses / joint diagnoses
support/counterevidence per hypothesis
required discriminating observations/tests
attempted discriminators + outcomes
repair methods associated with sufficiently supported diagnoses
status / bounds / provenance

Hard distinctions:

symptom pattern          != diagnosed fault
diagnostic hypothesis    != observed fact
single-fault heuristic   != proof only one fault exists
repair worked            != diagnosis historically proven
capability denial        != system fault
repair recommendation    != effect admission

Where no adequate behavioral model exists, heuristic rules and verified prior cases may propose hypotheses, but their weaker basis remains explicit.

Responsibilities

classify verifier failures, source inconsistencies, tool/effect failures, stale-preimage conflicts, missing evidence and blocked dependencies;
derive diagnostic conflicts when observations are incompatible with expected model/constraints;
construct explicit single or joint failure hypotheses with supporting/conflicting evidence;
use Project Knowledge / Git / Retrieval experts to acquire discriminating observations between live hypotheses;
distinguish evidence acquisition from mutation and prefer useful low-risk discriminators before destructive repair where policy requires;
map sufficiently supported diagnoses to typed repair procedure/method candidates;
prefer the smallest repair that preserves the exact Frozen Spec;
track attempted discriminators, repairs, strategies and actual outcomes;
detect repeated equivalent failure states and lack of progress;
return structured need_evidence, diagnosed, repair, ambiguous, blocked, exhausted, resource_limited, or unsupported results;
preserve diagnosis/repair lineage so later review can explain why each attempt happened.

Failure/repair knowledge

Support extensible rules/models for cases such as:

missing symbol/reference
stale source observation
preimage/head conflict
test assertion failure
compile/load failure
schema mismatch
capability/authority denial
ambiguous target
missing dependency
unexpected changed dependency
partial write/effect outcome
verification evidence missing
repeated equivalent failed edit
multi-fault / interacting failure

The expert must distinguish repairable defects from policy/authority denial and missing operator information. Do not retry an authority denial as if it were a coding bug and do not create a diagnostic fault solely to explain policy denial.

Hypothesis / conflict model

Represent diagnosis as inspectable data, for example:

hypothesis id/type
joint diagnosis membership where applicable
conflicts it explains
observations supporting it
observations against it
assumptions / expected-model version
required discriminating evidence
certainty/warrant class
repair methods considered
repair attempts/outcomes

Do not collapse all diagnosis into one opaque prose explanation or one magic confidence score.

Multiple hypotheses may remain live. If structural/resource bounds prevent resolution, return explicit ambiguity/resource-limited status rather than first-found diagnosis.

Discriminator selection

When more than one materially different diagnosis is live, permit a typed evidence-acquisition decision before repair:

candidate observation/test
which hypotheses it distinguishes
cost/work/risk class
required capability/authority
expected evidence type

Exact information-gain/cost optimization is profile/policy work for later Machine Spirit subpasses. The invariant here is that discriminating evidence is first-class and may be preferable to blind repair.

Procedural repair integration

Repair output should refer to or propose a typed procedural task/method candidate consumed by #379/#401A rather than directly executing arbitrary corrective code.

diagnosis
  -> applicable repair method(s)
  -> #379 procedure selection/decomposition/validation
  -> #288 plan graph
  -> normal expert/plan-native capability/effect path
  -> fresh observation
  -> #384 VERIFY

A successful repair may later become an episodic case/precedent with its verification receipt. It does not auto-promote itself into a trusted generic method/rule; #404 owns promotion.

No-progress / loop detection

Integrate with existing loop/detector work where appropriate. At minimum detect:

identical verifier failure fingerprint after equivalent repair;
repeated equivalent expert/tool invocation with no changed evidence;
repeated discriminator producing no new evidence;
repair cycling A→B→A;
repeated stale-preimage conflict without refreshing state;
exhausted diagnosis/repair strategy set;
repeated same projected diagnostic state;
budget/work/depth limits.

Stop structurally rather than spin forever.

LLM fallback

Normal diagnosis/repair selection uses Prolog rules/models and zero model calls.

An explicitly enabled model fallback may propose a candidate diagnosis, discriminator, or repair for unmodeled failures. That proposal is inert data and must be reconciled with current evidence, diagnosis semantics, expert/procedure applicability, Frozen Spec and capability rules before use.

Only the fallback call is metered.

Hard invariants

Frozen Spec fingerprint cannot change during diagnosis/repair.
Repair cannot delete/relax an obligation.
Diagnosis/repair cannot widen capability/authority.
Repair cannot convert unknown into satisfied without new admissible evidence.
Predicted procedural effects are not fresh observations.
Repair cannot bypass Write Expert for edit/create or plan-native semantics for D6-11 ops.
A case/precedent cannot become an admitted repair method merely because it is similar.
Capability/authority denial remains blocked/policy state unless separate evidence proves an actual system fault.
The final word remains VERIFY Expert.

Acceptance

Deterministic failure fixture produces an explicit diagnostic problem, hypothesis and correct repair/evidence subgoal with zero model calls.
Two competing hypotheses trigger a discriminating evidence request rather than arbitrary choice.
Discriminating evidence removes/weakens only hypotheses it actually contradicts and preserves provenance.
A multi-fault fixture can retain a joint diagnosis rather than forcing a single-fault explanation.
Stale-preimage conflict causes state refresh/re-resolution before another write attempt.
Authority denial returns blocked/policy outcome and is not retried/classified as an implementation fault.
Repair routes through #379 procedural method/network validation and edit/create through Write Expert.
Predicted repair postcondition alone cannot make diagnosis/VERIFY successful.
Exact Frozen Spec fingerprint is unchanged across every diagnosis/repair attempt.
Repeated equivalent failure/no-change diagnostic state terminates with explicit no-progress evidence.
Resource-bounded diagnosis returns explicit unresolved/resource-limited state rather than arbitrary winner.
Repair history, hypotheses, conflicts, discriminators and reasons are inspectable.
Successful verified repair may create an episodic case receipt but not auto-promote a trusted method/rule.
Optional model fallback is separately traced/metered and candidate output cannot bypass normal validation.
Successful repair still requires fresh VERIFY success.

Non-goals

No independent scheduler.
No self-verification.
No autonomous requirement weakening.
No universal probabilistic diagnosis requirement.
No automatic experience-to-rule promotion; #404 owns that boundary.

Refs #376 #377 #379 #380 #381 #382 #383 #384 #130 #397 #401.

Parent: #376 Depends on: #377, #384 Integrates with: #379, #380, #381, #382, #383 Research input: #397 #401A ## Goal Add a **Repair / Diagnosis Expert** that consumes structured VERIFY failures/unknowns/blocked states, performs explicit bounded diagnosis where ambiguity matters, and derives the smallest defensible next repair or evidence-acquisition subgoal without weakening the Frozen Spec. This expert is the core of the closed-loop retry path: ```text VERIFY not satisfied / unexpected observation -> classify failure/gap -> construct diagnostic conflict(s) where model/evidence permits -> derive competing hypotheses -> gather discriminating evidence if needed -> choose repair strategy only when sufficiently justified by policy -> return typed repair subgoal(s) -> Planner integrates an admitted procedural method/network -> execute -> re-observe -> VERIFY again ``` It does not directly declare success and does not own the scheduler. ## MACHINE-SPIRIT #401A refinement — diagnosis is not repair selection Depth 4A adopts the model-based diagnosis lesson from Reiter/de Kleer-style systems: **candidate explanation and corrective action are distinct reasoning products**. Preserve explicit diagnostic state equivalent to: ```text diagnostic problem id expected behavioral/causal model ref current observation refs conflict set(s) candidate hypotheses / joint diagnoses support/counterevidence per hypothesis required discriminating observations/tests attempted discriminators + outcomes repair methods associated with sufficiently supported diagnoses status / bounds / provenance ``` Hard distinctions: ```text symptom pattern != diagnosed fault diagnostic hypothesis != observed fact single-fault heuristic != proof only one fault exists repair worked != diagnosis historically proven capability denial != system fault repair recommendation != effect admission ``` Where no adequate behavioral model exists, heuristic rules and verified prior cases may propose hypotheses, but their weaker basis remains explicit. ## Responsibilities - classify verifier failures, source inconsistencies, tool/effect failures, stale-preimage conflicts, missing evidence and blocked dependencies; - derive diagnostic conflicts when observations are incompatible with expected model/constraints; - construct explicit single or joint failure hypotheses with supporting/conflicting evidence; - use Project Knowledge / Git / Retrieval experts to acquire discriminating observations between live hypotheses; - distinguish evidence acquisition from mutation and prefer useful low-risk discriminators before destructive repair where policy requires; - map sufficiently supported diagnoses to typed repair procedure/method candidates; - prefer the smallest repair that preserves the exact Frozen Spec; - track attempted discriminators, repairs, strategies and actual outcomes; - detect repeated equivalent failure states and lack of progress; - return structured `need_evidence`, `diagnosed`, `repair`, `ambiguous`, `blocked`, `exhausted`, `resource_limited`, or `unsupported` results; - preserve diagnosis/repair lineage so later review can explain why each attempt happened. ## Failure/repair knowledge Support extensible rules/models for cases such as: ```text missing symbol/reference stale source observation preimage/head conflict test assertion failure compile/load failure schema mismatch capability/authority denial ambiguous target missing dependency unexpected changed dependency partial write/effect outcome verification evidence missing repeated equivalent failed edit multi-fault / interacting failure ``` The expert must distinguish **repairable defects** from **policy/authority denial** and **missing operator information**. Do not retry an authority denial as if it were a coding bug and do not create a diagnostic fault solely to explain policy denial. ## Hypothesis / conflict model Represent diagnosis as inspectable data, for example: ```text hypothesis id/type joint diagnosis membership where applicable conflicts it explains observations supporting it observations against it assumptions / expected-model version required discriminating evidence certainty/warrant class repair methods considered repair attempts/outcomes ``` Do not collapse all diagnosis into one opaque prose explanation or one magic confidence score. Multiple hypotheses may remain live. If structural/resource bounds prevent resolution, return explicit ambiguity/resource-limited status rather than first-found diagnosis. ## Discriminator selection When more than one materially different diagnosis is live, permit a typed evidence-acquisition decision before repair: ```text candidate observation/test which hypotheses it distinguishes cost/work/risk class required capability/authority expected evidence type ``` Exact information-gain/cost optimization is profile/policy work for later Machine Spirit subpasses. The invariant here is that **discriminating evidence is first-class** and may be preferable to blind repair. ## Procedural repair integration Repair output should refer to or propose a typed procedural task/method candidate consumed by #379/#401A rather than directly executing arbitrary corrective code. ```text diagnosis -> applicable repair method(s) -> #379 procedure selection/decomposition/validation -> #288 plan graph -> normal expert/plan-native capability/effect path -> fresh observation -> #384 VERIFY ``` A successful repair may later become an episodic case/precedent with its verification receipt. It does not auto-promote itself into a trusted generic method/rule; #404 owns promotion. ## No-progress / loop detection Integrate with existing loop/detector work where appropriate. At minimum detect: - identical verifier failure fingerprint after equivalent repair; - repeated equivalent expert/tool invocation with no changed evidence; - repeated discriminator producing no new evidence; - repair cycling A→B→A; - repeated stale-preimage conflict without refreshing state; - exhausted diagnosis/repair strategy set; - repeated same projected diagnostic state; - budget/work/depth limits. Stop structurally rather than spin forever. ## LLM fallback Normal diagnosis/repair selection uses Prolog rules/models and zero model calls. An explicitly enabled model fallback may propose a candidate diagnosis, discriminator, or repair for unmodeled failures. That proposal is inert data and must be reconciled with current evidence, diagnosis semantics, expert/procedure applicability, Frozen Spec and capability rules before use. Only the fallback call is metered. ## Hard invariants - Frozen Spec fingerprint cannot change during diagnosis/repair. - Repair cannot delete/relax an obligation. - Diagnosis/repair cannot widen capability/authority. - Repair cannot convert `unknown` into `satisfied` without new admissible evidence. - Predicted procedural effects are not fresh observations. - Repair cannot bypass Write Expert for `edit/create` or plan-native semantics for D6-11 ops. - A case/precedent cannot become an admitted repair method merely because it is similar. - Capability/authority denial remains blocked/policy state unless separate evidence proves an actual system fault. - The final word remains VERIFY Expert. ## Acceptance - [ ] Deterministic failure fixture produces an explicit diagnostic problem, hypothesis and correct repair/evidence subgoal with zero model calls. - [ ] Two competing hypotheses trigger a discriminating evidence request rather than arbitrary choice. - [ ] Discriminating evidence removes/weakens only hypotheses it actually contradicts and preserves provenance. - [ ] A multi-fault fixture can retain a joint diagnosis rather than forcing a single-fault explanation. - [ ] Stale-preimage conflict causes state refresh/re-resolution before another write attempt. - [ ] Authority denial returns blocked/policy outcome and is not retried/classified as an implementation fault. - [ ] Repair routes through #379 procedural method/network validation and edit/create through Write Expert. - [ ] Predicted repair postcondition alone cannot make diagnosis/VERIFY successful. - [ ] Exact Frozen Spec fingerprint is unchanged across every diagnosis/repair attempt. - [ ] Repeated equivalent failure/no-change diagnostic state terminates with explicit no-progress evidence. - [ ] Resource-bounded diagnosis returns explicit unresolved/resource-limited state rather than arbitrary winner. - [ ] Repair history, hypotheses, conflicts, discriminators and reasons are inspectable. - [ ] Successful verified repair may create an episodic case receipt but not auto-promote a trusted method/rule. - [ ] Optional model fallback is separately traced/metered and candidate output cannot bypass normal validation. - [ ] Successful repair still requires fresh VERIFY success. ## Non-goals - No independent scheduler. - No self-verification. - No autonomous requirement weakening. - No universal probabilistic diagnosis requirement. - No automatic experience-to-rule promotion; #404 owns that boundary. Refs #376 #377 #379 #380 #381 #382 #383 #384 #130 #397 #401.

nsaspy commented

2026-09-08 01:46:49 +00:00

Author

Owner

Machine Spirit #401B canonical handoff — diagnosis under nondeterminism, exogenous change, and risky tests

Depth 4B strengthens this diagnosis contract:

Unexpected post-effect state must classify at least: declared nondeterministic outcome, primitive action/tool failure, exogenous world change, stale precondition evidence, operator/model defect, concurrent interference, partial effect, or observation error. Do not jump directly from predicted != observed to fault(Action).
Preserve four distinct repair targets: execution/dispatch continuation; current plan-instance repair; method reselection; inert reusable-method defect/supersession candidate. A failed run does not mutate trusted method knowledge.
A successful repair does not prove the diagnosis that motivated it.
Candidate discriminators must preserve: hypotheses separated, expected observation classes, cost/work/time, risk/destructiveness, reversibility, authority/capability, resource requirement, and freshness. Safety/authority may dominate information gain.
Destructive mutation must not be used merely as a diagnostic test when a lower-risk admissible observation distinguishes the same live hypotheses.
Capability/authority denial stays a policy/blocked state unless separate evidence proves a system defect.
Exogenous changes should be classified against the current execution frontier so only threatened guards/causal links/resources are repaired; unrelated events do not trigger global replanning.
Repeated strong-cyclic/retry strategies require explicit progress/fairness assumptions and bounded no-progress detection; retry until success is not a guarantee.

Full rationale, sources and B1-B28 fixtures are in #401 Depth-4B.

## Machine Spirit #401B canonical handoff — diagnosis under nondeterminism, exogenous change, and risky tests Depth 4B strengthens this diagnosis contract: - Unexpected post-effect state must classify at least: declared nondeterministic outcome, primitive action/tool failure, exogenous world change, stale precondition evidence, operator/model defect, concurrent interference, partial effect, or observation error. Do not jump directly from `predicted != observed` to `fault(Action)`. - Preserve four distinct repair targets: execution/dispatch continuation; current plan-instance repair; method reselection; inert reusable-method defect/supersession candidate. A failed run does not mutate trusted method knowledge. - A successful repair does **not** prove the diagnosis that motivated it. - Candidate discriminators must preserve: hypotheses separated, expected observation classes, cost/work/time, risk/destructiveness, reversibility, authority/capability, resource requirement, and freshness. Safety/authority may dominate information gain. - Destructive mutation must not be used merely as a diagnostic test when a lower-risk admissible observation distinguishes the same live hypotheses. - Capability/authority denial stays a policy/blocked state unless separate evidence proves a system defect. - Exogenous changes should be classified against the current execution frontier so only threatened guards/causal links/resources are repaired; unrelated events do not trigger global replanning. - Repeated strong-cyclic/retry strategies require explicit progress/fairness assumptions and bounded no-progress detection; `retry until success` is not a guarantee. Full rationale, sources and B1-B28 fixtures are in #401 Depth-4B.

nsaspy commented

2026-09-08 01:46:50 +00:00

Author

Owner

Machine Spirit #401D handoff — bounded incremental diagnosis/repair

Depth 4D makes diagnosis execution explicitly query/run-local, bounded, incrementally reusable derived state.

preserve conflict sets / live diagnoses / discriminator outcomes as structured state for the current diagnostic problem;
permit incremental conflict reuse and bounded hitting-set/dual search rather than global all-diagnoses materialization;
parallel conflict/hitting-set work may use the existing runtime, but normalized diagnosis ordering/set/receipt must not depend on thread completion order;
bounds cover conflicts, diagnosis cardinality, live diagnoses, discriminators, measurements/tests and total work; exhaustion is resource_limited, never arbitrary first diagnosis;
repair strategy must preserve the B distinction among continuation repair, plan-instance repair, method reselection and reusable-method-defect candidate;
successful repair still does not prove the diagnosis and never auto-promotes a method.

Relevant primary work: Jannach/Schmitz/Shchekotykhin AAAI 2015 parallel hitting sets without losing diagnoses (https://ojs.aaai.org/index.php/AAAI/article/view/9389) and Rodler/Herold StaticHS for sequential diagnosis (https://ojs.aaai.org/index.php/SOCS/article/view/18449).

Full DPEC design + D26/D27 diagnosis fixtures are on #401.

## Machine Spirit #401D handoff — bounded incremental diagnosis/repair Depth 4D makes diagnosis execution explicitly **query/run-local, bounded, incrementally reusable derived state**. - preserve conflict sets / live diagnoses / discriminator outcomes as structured state for the current diagnostic problem; - permit incremental conflict reuse and bounded hitting-set/dual search rather than global all-diagnoses materialization; - parallel conflict/hitting-set work may use the existing runtime, but normalized diagnosis ordering/set/receipt must not depend on thread completion order; - bounds cover conflicts, diagnosis cardinality, live diagnoses, discriminators, measurements/tests and total work; exhaustion is `resource_limited`, never arbitrary first diagnosis; - repair strategy must preserve the B distinction among continuation repair, plan-instance repair, method reselection and reusable-method-defect candidate; - successful repair still does not prove the diagnosis and never auto-promotes a method. Relevant primary work: Jannach/Schmitz/Shchekotykhin AAAI 2015 parallel hitting sets without losing diagnoses (https://ojs.aaai.org/index.php/AAAI/article/view/9389) and Rodler/Herold StaticHS for sequential diagnosis (https://ojs.aaai.org/index.php/SOCS/article/view/18449). Full DPEC design + D26/D27 diagnosis fixtures are on #401.

nsaspy commented

2026-09-08 01:46:50 +00:00

Author

Owner

MACHINE-SPIRIT #404A handoff — diagnosis/repair experience

EPOCH consumes #385 outcomes as immutable learning experience, but preserves:

repair succeeded != diagnosis proven
failure episode   != negative example by default
authority denial  != implementation fault
resource exhaustion/cancel != semantic failure

A verified repair may seed EBG/case/ILP candidate generation only with its exact diagnosis assumptions, observations, discriminators, repair method/version, VERIFY receipt, Review findings and replay lineage. Promotion remains a separate #404 policy decision with counterexample/independence checks. Regressions against an admitted learned repair strategy can append suspension/supersession evidence without rewriting the historical episode.

Ref #404A EPOCH.

## MACHINE-SPIRIT #404A handoff — diagnosis/repair experience EPOCH consumes #385 outcomes as immutable learning experience, but preserves: ```text repair succeeded != diagnosis proven failure episode != negative example by default authority denial != implementation fault resource exhaustion/cancel != semantic failure ``` A verified repair may seed EBG/case/ILP candidate generation only with its exact diagnosis assumptions, observations, discriminators, repair method/version, VERIFY receipt, Review findings and replay lineage. Promotion remains a separate #404 policy decision with counterexample/independence checks. Regressions against an admitted learned repair strategy can append suspension/supersession evidence without rewriting the historical episode. Ref #404A EPOCH.

nsaspy commented

2026-09-08 01:46:50 +00:00

Author

Owner

Machine Spirit #404B / CITADEL-EPOCH handoff

Learning labels must consume the diagnosis/failure class rather than raw success/failure:

failed episode != negative example for every rule/method/strategy involved
successful episode != positive example for every component involved

Preserve whether the episode was caused/blocked by method defect, plan-instance defect, stale evidence, authority denial, resource exhaustion, exogenous/transient failure, verifier uncertainty, or unresolved multi-fault diagnosis. Only sufficiently supported causal attribution may feed the corresponding learning lane as a counterexample/positive example; unresolved attribution stays explicit.

This prevents authority/resource/transient failures from poisoning procedural learning and prevents a successful repair from retrospectively proving the original diagnosis. Refs #404B CITADEL fixtures B21-B24.

## Machine Spirit #404B / CITADEL-EPOCH handoff Learning labels must consume the diagnosis/failure class rather than raw success/failure: ```text failed episode != negative example for every rule/method/strategy involved successful episode != positive example for every component involved ``` Preserve whether the episode was caused/blocked by method defect, plan-instance defect, stale evidence, authority denial, resource exhaustion, exogenous/transient failure, verifier uncertainty, or unresolved multi-fault diagnosis. Only sufficiently supported causal attribution may feed the corresponding learning lane as a counterexample/positive example; unresolved attribution stays explicit. This prevents authority/resource/transient failures from poisoning procedural learning and prevents a successful repair from retrospectively proving the original diagnosis. Refs #404B CITADEL fixtures B21-B24.

nsaspy commented

2026-09-08 01:46:50 +00:00

Author

Owner

MACHINE-SPIRIT #404D / CLOCKWORK handoff

Diagnosis remains upstream evidence-labeling input, not permission to rewrite a frozen evaluation. CLOCKWORK requires learning relevance to preserve the exact diagnosis/failure-class receipt used when an experience becomes positive/negative/context evidence.

After an EvaluationSnapshot is frozen, later diagnosis repair/reclassification is a new evidence/lifecycle event and may invalidate/restart evaluation; it cannot mutate old labels in place to rescue a candidate. Authority denial, stale evidence, resource exhaustion and exogenous/transient failure remain distinct from method/rule failure.

Counterexample/minimized-failure witnesses should link back to the exact diagnostic problem and observation generations when applicable. Refs #397 #404 #384 #395.

## MACHINE-SPIRIT #404D / CLOCKWORK handoff Diagnosis remains upstream evidence-labeling input, not permission to rewrite a frozen evaluation. CLOCKWORK requires learning relevance to preserve the exact diagnosis/failure-class receipt used when an experience becomes positive/negative/context evidence. After an EvaluationSnapshot is frozen, later diagnosis repair/reclassification is a **new evidence/lifecycle event** and may invalidate/restart evaluation; it cannot mutate old labels in place to rescue a candidate. Authority denial, stale evidence, resource exhaustion and exogenous/transient failure remain distinct from method/rule failure. Counterexample/minimized-failure witnesses should link back to the exact diagnostic problem and observation generations when applicable. Refs #397 #404 #384 #395.