3. Classify stale, duplicate-candidate, contradiction, missing-link or insufficient-context findings. Explain the proposed change and its evidence. Exact name/alias matches are review candidates only; verify identity and preserve each source's provenance before proposing a relationship. Similarity alone cannot decide a merge.
4. Preserve claims that disagree. Propose a typed `contradicts` relationship with evidence or explicitly labeled interpretation rationale; do not collapse either claim. For substantive relationships, include the supporting evidence or rationale and record material conditions such as population, time period or setting. Record assumptions and limitations as separately assessed node claim groups with assertion paths `assumptions[n].text` and `limitations[n].text`; do not treat edge conditions as a substitute for those claims.
5. For report-only work, stop with findings and coverage. For authorized contributions, build separate typed proposals with expected revisions and affected policy domains.
6. Resolve validation findings and inspect receipts. A held merge or promotion is a pending exception; it is not permission to copy/delete records manually.
Checkpoint candidate IDs, inspected revisions, findings, proposed changes and receipts. After another agent changes a candidate, re-inspect before resuming its proposal. Keep completed findings and unexamined coverage distinct.
