Training › Module 03

Module 03 — The Senior Reviewer

Team leaders, senior advisors, and subject-matter experts who quality-check first-pass review and make the harder withholding calls · 30–40 minutes · Prerequisites: Module 00 — Foundation and Module 02 — The Reviewer (this module covers only what is added at the senior tier)

In a hurry? Jump to the quick-reference card or the knowledge check — or print the all-roles reference.

Learning objectives

By the end of this module you can:

1. Quality-check another reviewer’s decisions and send a document back with “Request Changes” → “Send Back”.
2. State precisely what a Senior Reviewer cannot do — and why final sign-off is a separate role.
3. Make disclosure decisions, including withholding a document in full where your regime allows it.
4. Use the senior-tier tools on the “Bulk review” page: the “Auto-accept high-confidence detections” sweep, “Auto-clear structured PII (emails, phone numbers, IDs)”, and “Hide everywhere” in “Review by reach”.
5. Compare version snapshots to see exactly what changed between review milestones.

1. What changes at this tier

Everything from Module 02 still applies — you can open documents, decide detections, assign grounds, and sign off a first-pass review. On top of that, the Senior Reviewer is the quality-check tier: you review decisions, not just documents. Your visibility remains department-scoped unless it has been widened, and every action is still authorised by the server against your role and department.

You also gain a package right: a Senior Reviewer can produce the “Internal Package” as well as the “Requester Package” (the “Ombudsman Package” stays with the Final Approver and the Lead).

2. Reviewing others’ decisions

Open a document in “Reviewed (Initial)” and work the “Detections” panel as an auditor:

• Check each “redacted” and “kept visible” decision against the content and its ground. Use the card’s “Reasoning”, “AI Explanation”, “Public Interest Consideration”, and “Change History” to see how the decision was reached.
• Pay particular attention to [REVIEW REQUIRED] types (legal privilege, safety, law enforcement) and to any detections the reviewer left undecided at sign-off — those are escalated to you for a senior decision.
• Middle-section grounds require a public-interest test — satisfy yourself the balancing actually holds, not just that a ground is attached.

3. Request Changes → Send Back

When a document is not right:

1. Press “Request Changes”
2. Confirm with “Send Back” adding a reason (optional, but always write one — it goes to the reviewer and saves a conversation).
3. The document returns to “In Review” and reappears in the reviewer’s queue.

Send-back only works before final approval. Once a Final Approver has signed a document off it is frozen — so raise problems early.

4. What you cannot do

• No final sign-off. The “Final Approval” action belongs to the Final Approver and the Lead. This is deliberate separation of duties: the person who quality-checks the review is not the person who authorises release.
• No case creation or administration, no deadline setting or extension, no document deletion — those are the Lead’s.
• No “Ombudsman Package” — on the export screen a package your role cannot produce is disabled with “Your role cannot emit this package type”.

5. Disclosure decisions

The senior tier makes the formal disclosure calls — including withholding a document in full rather than span-by-span.

Where available (Senior Reviewer / Final Approver / Lead):

• On the case’s Documents tab, select documents and choose “Mark as PE”; the “Show PE only” chip filters the list to them.
• In a public-excluded document’s review screen, the card offers “Apply withhold in full”; its confirm dialog warns: “The entire document will be withheld under LGOIMA s48 — no per-span review or partial release.”
• The decision is reversible (“Revert to per-span review”) while the document is still in review, and locked once signed off.

6. Bulk tools at the senior tier — the “Bulk review” page

Reference: bulk review in the feature reference

For large requests, open the “Bulk review” page with “Bulk Review” from the Documents tab. Its promise sits under the title: “Apply one redaction decision across many documents at once — highest-reach detections first.” A scope chip shows what you are reviewing (for example “Reviewing all {N} documents”, or “Reviewing {N} of {M} documents · limited to your department”), and a case-wide meter tracks “{N} of {M} detections cleared” with “{N} left to review”. The page works in three numbered, collapsible steps:

Step 1 — “Auto-accept high-confidence detections”

(Lead / Senior Reviewer — the apply button is hidden from other roles, who see “Auto-accepting by confidence is a senior-reviewer action.”)

Set the “Confidence threshold” slider (tick shortcuts at 0/50/70/85/90/95/100; default 85%). Three tiles preview the effect live: “auto-accept above {X}%”, “held for manual review”, and “documents affected”. Press “Show the {N} detections this will redact” to see the literal released result — the entries closest to the threshold first, each untickable to keep it visible — then commit with “Auto-accept {N} above {X}%”. Each accepted detection keeps its own suggested ground and updates the withholding schedule.

Step 2 — “Auto-clear structured PII (emails, phone numbers, IDs)”

(Senior Reviewer / Final Approver / Lead — others see “Clearing structured PII case-wide is a senior-reviewer action.”)

One chip per structured identifier type with a live count — “Redact all phone numbers”, “Redact all email addresses”, “Redact all IRD numbers”, and so on (addresses, bank account numbers, passport numbers, vehicle registrations, NHI numbers). One press decides every pending detection of that type case-wide. This sweep is deliberately fenced to structured PII: as the page puts it, “Names, commercial information and legal grounds aren’t offered here” — those depend on who and why, so they route to Step 3. The fence is enforced server-side, not just in the UI.

Step 3 — “Review by reach”

(open to every case participant; the assignment and department rules still apply)

Veil groups repeated values into entity groups — most-repeated first; one-off detections are reviewed in the document itself, not here. Each card shows the value, what it looks like (“Looks like a person’s name”), a confidence band (“High confidence” / “Medium confidence” / “Low confidence”), and its reach: “appears {N} times” “across {N} documents”. A preview shows “If hidden, this is what’s released” with the withholding ground, revealable with “Reveal original”. Filter with “Search entities…” and the type chips. Three moves per card:

• “Hide everywhere” — accept the whole group case-wide under its ground (Senior Reviewer / Final Approver / Lead; only shown when the group carries a determinable ground).
• “Look first” — open the first affected document for per-occurrence review when context matters.
• “Not sensitive” — reject the group: it stays visible in the release.

A decided card reads “Hidden in {N} documents” or “Kept visible — not sensitive”, with “Change” to clear the decision. After any batch action a banner offers “Review these {N}” and “Undo this batch”. When “{N} detections still need a decision” reaches zero, “Continue to sign-off” unlocks.

7. Custom detection rules

Senior Reviewers share the “Custom Rules” screen with the Lead — agency-specific keywords, patterns, and entities mapped to withholding grounds, running alongside the AI. They are detection rules, not redaction rules: a match becomes an ordinary detection for a person to decide, and only Active rules run. The full walkthrough is in Module 01; as the tier that sees recurring patterns across reviews, you are often best placed to propose and author them.

8. Comparing version snapshots

Reference: version snapshots in the feature reference

Veil snapshots a document’s redaction decisions at each milestone, so you can see exactly what changed — ideal for checking a document that has come back after a send-back.

• Open “Compare” (the “Compare version snapshots” button) from the review toolbar.
• Choose a “Left Version” and “Right Version” — any snapshot or “Current State”. Snapshots are labelled “Draft (Submitted for Review)” and “Final (Signed Off)”.
• Each detection is marked “Added”, “Removed”, “Modified”, or “Unchanged”, with “Left Ground” / “Right Ground” columns so a changed statutory ground stands out.
• The “Summary:” pills (unchanged / modified / added / removed) filter the table.

Hands-on exercise

On the demo instance, using a case with documents already in “Reviewed (Initial)”:

1. Open a reviewed document and audit three decisions using “Reasoning” and “Change History”. Find the planted error (a mis-grounded redaction).
2. Press “Request Changes” → “Send Back” with a one-line reason. Confirm the badge returns to “In Review”.
3. After your trainer’s “reviewer” fixes and re-signs it, open “Compare version snapshots”, set “Left Version” to “Draft (Submitted for Review)” and “Right Version” to “Current State”, and use the “Summary:” pills to isolate the “Modified” detection. Check its “Left Ground” / “Right Ground”.
4. From the Documents tab, open “Bulk Review”. In “Review by reach”, pick an entity group spanning several documents, press “Reveal original” to check the value, then “Hide everywhere”. Find a group showing “This needs a closer look.” and explain why it only offers “Review these {N} individually”.
5. In “Auto-accept high-confidence detections”, set the “Confidence threshold” slider, read the “auto-accept above {X}%” / “held for manual review” / “documents affected” tiles, open “Show the {N} detections this will redact”, then press “Auto-accept {N} above {X}%” — and practise “Undo this batch” from the banner. Try one “Redact all phone numbers” chip in “Auto-clear structured PII”.
6. (LGOIMA demo instances only) Select a document, choose “Mark as PE”, open it, and press “Apply withhold in full”; then use “Revert to per-span review” to undo it.
7. Attempt a final sign-off and observe that “Final Approval” is not available to your role.

Quick-reference card