Reviewer Notes with Immutable Version History

Reviewer notes are EvidAI's mechanism for capturing human reasoning alongside the audit trail. Where the audit trail records what happened, reviewer notes record why the reviewer made that call. Every note is immutable, versioned, and cryptographically chained.

Scopes

A note can be attached to any of four scopes:

• Review — whole-review commentary (strategic notes, methodology decisions)
• Phase — phase-level commentary (protocol, search, screening, extraction, risk-of-bias, synthesis, report-prep, manuscript, visuals, updates)
• Paper — specific to one paper in the review
• Extraction-field — specific to one extracted field on one paper (e.g. "sample_size on paper-42")

How to Open the Notes Panel

For the whole review

1. Open the SLR hub (/slr).
2. In the header action row, click "Reviewer Notes".
3. A modal appears with the immutable version chain scoped to the review.

For a phase, paper, or field

Each SLR phase page exposes a ReviewerNoteHistory panel in the relevant context (e.g. the extraction field inspector shows the note history for that specific field on that paper).

Version Chain

Every time a reviewer creates, edits, or tombstones a note:

1. A new version is appended — the body is never overwritten.
2. The new version is linked to its predecessor by a previous-hash pointer.
3. The new version's content hash is computed deterministically from the payload.

Tombstoned versions remain in the chain — only their bodies are hidden from the digest view. This preserves auditability: you cannot retroactively remove a note without leaving a verifiable gap.

Hash Integrity

Each version carries:

• A stable note identifier shared across every version of the same note
• A 1-indexed, monotonically increasing version number
• A content hash over the canonical payload (scope, body, author, timestamp)
• A previous-hash pointer (or null for v1)
• An action label: create, edit, or tombstone

The chain is verified at export time and per-note integrity verdicts are written into the export bundle.

Export Bundle Contents

Every export bundle ships two reviewer-notes artifacts in a reviewer-notes directory:

• A machine-readable append-only version chain (mirrors the audit directory pattern). Includes per-note integrity verdicts and the full versions array.
• A human-readable digest of the latest-per-note view. Shows scope, note id, latest version, author, and body for each non-tombstoned note, prefaced by a chain integrity summary.

Use Cases

• Methodology decisions — "Decided to exclude cluster-RCTs because cluster effect sizes are not reported in any eligible study."
• Discrepancy rationale — "Reviewer 1 marked include; Reviewer 2 marked exclude on population mismatch. Adjudicator (me) agrees with Reviewer 2 after re-reading section 2.1."
• Extraction uncertainty — "Authors report sample size of 342 in text but table 1 shows 348. Using 342 per protocol section 7.3."
• Protocol amendments — "Amended search on 2026-02-14 to include CINAHL after peer review raised it. Justification in PROSPERO amendment #2."

Best Practices

• One note per decision, not per session. Each decision gets its own noteId; edits to that decision are new versions of the same note.
• Reference the underlying record. Paper-scoped notes should mention the title/DOI; field-scoped notes the field and paper.
• Use scope deliberately. If the note is about one extraction field, scope it to extraction-field, not paper — it keeps the digest focused.
• Never delete — tombstone a note instead if it becomes irrelevant. The chain must remain contiguous for integrity verification.

Relationship to the Audit Trail

Reviewer notes and the 21 CFR Part 11 audit trail are complementary, not overlapping:

Both are immutable, both are cryptographically chained, and both are included in every export bundle.