CR-080: Align signed event backlog status

docs/current_backlog.md

@@ -7,8 +7,8 @@ This document summarizes the active TriageCore backlog after CR-079.
 ## Active GitHub Backlog
 
 - Issue #72: Expand signed ledger event coverage beyond `route_audit`
-  - Status: partially implemented by CR-078 and CR-079
-  - Purpose: selectively enforce identity checks and signatures for core ledger events beyond `route_audit` without treating signatures as approval. CR-078 adds the first additional signed path for `validation_result`, and CR-079 adds operator-facing verification for that signed event; broader event coverage remains future work.
+  - Status: `validation_result` path complete via CR-078 and CR-079; broader event coverage remains future work
+  - Purpose: selectively enforce identity checks and signatures for core ledger events beyond `route_audit` without treating signatures as approval. The first additional signed-event path now covers `validation_result` creation plus operator-facing verification; future work is deciding whether to sign additional event types such as `route_decision`, `taskpacket_created`, or `project_steward_decision`.
 
 - Issue #73: Implement runtime key rotation behavior
   - Status: open
@@ -98,15 +98,15 @@ This document summarizes the active TriageCore backlog after CR-079.
 
 Keep three work lanes distinct:
 
-- Identity lifecycle work #4 is closed. CR-078 partially implements Issue #72 by adding signed `validation_result` ledger events; remaining signed-event expansion and Issue #73 runtime rotation behavior should stay separate implementation slices.
+- Identity lifecycle work #4 is closed. CR-078 and CR-079 complete the signed `validation_result` path under Issue #72; remaining signed-event expansion and Issue #73 runtime rotation behavior should stay separate implementation slices.
 - Model and runtime integrity work should build on CR-031 through CR-033. Keep
   policy baseline, route-manifest artifact shape, manifest validation, and live
   enforcement as separate reviewable slices.
 - Repository consistency and secrets hygiene from CR-034 is complete. Future
   hygiene work should be limited to stale documented claims or a separately
   proposed repo-consistency checker.
 
-For signed ledger coverage, the next slice should deliberately choose one more event type or move into key lifecycle behavior. Do not treat a valid signature as approval, safety, or correctness.
+For signed ledger coverage, keep the `validation_result` path stable and legible, then choose deliberately between reviewer-facing verification docs/examples or one additional signed event type. Do not treat a valid signature as approval, safety, or correctness.
 
 For the empirical AI safety evaluation track, keep the next slices sequential: fixture validation first, evaluator CLI second, and broader adversarial/tampering studies only after the fixture contract is stable.