Investigate direct predecessor-graph reconstruction for Gatekeeper

[macterra]

Question

Can cold reconstruction compute the selected histories directly from predecessor-linked operations and their retained events, with less code and work than repeated importer passes until serialized event histories stop changing?

This is the fourth, highest-risk opportunity in the simplification order. Start after the ordering, event-policy and history-interpretation issues so a prototype can reuse explicit semantics. The deliverable here is an investigation and a go/no-go recommendation, not an assumed production rewrite.

Investigation

• Prototype direct reconstruction in isolation: normalize retained evidence, reconstruct self-controlled agents, then derive asset authorization from the actual agent results and select asset paths.
• Preserve every retained candidate and distinct chain anchor. Normalize richer same-position copies before authorization; select among authorized events, without inventing a proof-time fallback for a rejected chain event.
• Account for late/missing genesis and predecessors, cached predecessor aliases, competing branches, key/registry changes, transfers, deletion, earlier anchors, enrichment, and rejected evidence becoming valid later.
• Do not assume the candidate journal obeys all accepted-history invariants: mixed-type creates and misaddressed candidates already require care in replay scheduling.
• Derive preference from each predecessor's registry. Global CID sorting or ordinal comparisons across registries are not replacements for the protocol rule.

Acceptance criteria for recommending replacement

• Establish algorithm-level equivalence to the existing canonical result/operational model, including termination, full component/deactivation state, controller authorization views and event-representation stopping behavior where relevant.
• Distinguish that proof from universal TypeScript/Rust verification. Run the shared signed source vectors through the prototype and both current implementations, including repeat delivery and real storage restart.
• Preserve public resolution/export metadata and behavior, not merely the operation-ID path. Document how the existing harmless first-observation representation choices are retained.
• Compare reconstructed populated histories canonically, as well as counters and search/query results, on isolated production-scale snapshots with matching persistence settings. Measure wall time, memory and database work for unchanged startup, repair and late-evidence recovery. Do not mutate the running node.
• Preserve atomic publication/history locking and dependent replay. Do not replace efficient incremental imports with unconditional whole-database reconstruction.
• Report whether the algorithm is actually simpler and faster; retain the existing loop if equivalence or practical benefit cannot be established. Scope any production implementation separately from the prototype findings.

The completed protocol proof provides a reference result, not an automatic proof of this new implementation. This is a separate optimization investigation and does not extend or reopen #1215/A1–C3.

Pointers: TypeScript reconcileHistoryOnce; Rust history.rs; Lean RegistryPriority.lean, PriorityProjection.lean, ProtocolModel.lean, ProtocolConvergence.lean.

Dependencies

Tackle after #1246 (Share Gatekeeper history interpretation across resolution and authorization).

Agreed execution order

1. Simplify Gatekeeper successor ordering with one pure comparator #1244 — Simplify Gatekeeper successor ordering with one pure comparator
2. Consolidate Gatekeeper event normalization and evidence policy #1245 — Consolidate Gatekeeper event normalization and evidence policy
3. Share Gatekeeper history interpretation across resolution and authorization #1246 — Share Gatekeeper history interpretation across resolution and authorization
4. Investigate direct predecessor-graph reconstruction for Gatekeeper #1247 — Investigate direct predecessor-graph reconstruction for Gatekeeper