Diagnose stale acceptance evidence and recovery conflicts

Understand the likely causes

• Possible causes include cache keys that omit candidate or evaluator identity, reused display names, mutable aliases resolved at different moments, stale selection decisions, missing dependencies, and recovery packages with incompatible schemas. A recent report timestamp or an accepted tag cannot resolve these conflicts by itself.

1. Resolve names into concrete artifacts and evidence

Record the proposed package, current selected version, actual consumer version, evaluation report, cohort, evaluator, transform, schema, and recovery package identities. Resolve mutable aliases once at the boundary being investigated and preserve their generation or equivalent previous-state evidence. A consumer may legitimately retain an older pinned version, so distinguish delayed adoption from an inconsistent mixed package. Check content and contract identities rather than only friendly names or creation times. Preserve the original mismatch as a synthetic fixture without contacting or mutating a real registry.

2. Trace the report’s producing execution and cache key

Follow the report to the exact evaluated package and data boundary, including metric rules and label maturity. Inspect whether reuse captured all relevant inputs: candidate content, schema, evaluator code, configuration, split and cohort identity, and any fitted transform. A task-name-only cache key can reuse a correct old report for the wrong candidate. A cache hit means old output was reused; it does not establish a fresh evaluation. If the key omitted a dependency, invalidate affected evidence under the supported system process and recompute the appropriate evaluation rather than editing the report’s package name.

3. Check acceptance and recovery independently

The fixture contains an accepted report for model-1 and a proposed model-2 with another schema. It also retains a recovery package whose schema is incompatible with the proposed process. Both prerequisites fail for different reasons. Do not treat report acceptance as authority for another artifact or package availability as proof of recoverability. Inspect feature availability, label mappings, runtime, transform state, and consumer interface as well as the old file. A generation or conditional-update mechanism also needs to prevent an old decision from overwriting a newer selection without detecting the conflict.

candidate = {"id":"model-2","schema":"schema-2"}
report = {"package":"model-1","accepted":True}
recovery = {"available":True,"schema":"schema-1"}
checks = {"matching candidate evidence":report["accepted"] and report["package"] == candidate["id"],
          "compatible recovery":recovery["available"] and recovery["schema"] == candidate["schema"]}
print("unmet", [name for name,passed in checks.items() if not passed])
print("declared change ready", all(checks.values()))

unmet ['matching candidate evidence', 'compatible recovery']
declared change ready False

4. Rebuild a consistent evidence and recovery chain

Produce matching evaluation under the declared cohort, restore or redesign compatible recovery prerequisites, and apply only the supported decision procedure. Verify the exact version consumers resolve and a known raw-input result through the complete package. Test alias movement, stale decisions, missing cached artifacts, failed publication, and rollback dependencies as separate cases. If earlier reports were reused incorrectly, mark their scope as invalidated rather than silently replacing history. Registration, accepted evaluation, selected version, successful delivery, and observed outcomes remain distinct facts even after the identity conflict is repaired.

Keep it from recurring

• Keep content-aware cache keys, immutable report links, explicit alias-resolution boundaries, and recovery dependencies alongside the release record. Test mismatched reports and stale decisions before automating selection, and retain the artifacts required by the supported investigation and recovery objectives.