# Phase 6 Reviewer Wireframes — Text Overview

`specs/phase-6/reviewer-journeys-draft.md` is the source of truth for the workflow represented here.

## Preferred design

The preferred Phase 6 reviewer UI is:

`specs/phase-6/wireframes/phase-6-govuk-disciplined-workbench-wireframes.html`

This design combines an expert review workbench with GOV.UK-style interaction discipline:

- retain dense evidence and side-by-side comparison where expert review benefits from simultaneous context;
- use plain-language task headings and restrained visual hierarchy;
- distinguish navigation links from state-changing actions;
- avoid clusters of competing durable-action buttons;
- record durable reviewer conclusions through an explicit decision step and confirmation where the action changes reviewer state or problem associations;
- keep Act-level QA completion distinct from semantic investigation conclusions;
- use conventional, accessible form controls and clear confirmation/error patterns;
- keep exploratory notebook material separate from durable observations, conclusions and problem evidence.

The preferred wireframe now includes the settled Act-level QA and approval interaction. The other HTML wireframes in this directory remain design explorations and comparison material rather than the preferred design.

## Workspaces

1. **Explore Acts** — exploration of all transformed Acts through distinct **Findings and processing**, **QA focus** and **All transformed Acts** lenses.
2. **Investigate Provision** — the central provision-level source/output investigation workspace, presented as a compact expert comparison workbench with a full-width investigation notebook below it.
3. **Review Problem** — management of an understood reviewer problem as a structured case record, with evidence, lifecycle, rechecks and retained investigation context.

Act-level approval summary/final approval are supporting flows within the reviewer application, not a fourth primary workspace. The rendered transformed-Act view is a separate read-only reference surface, also not a primary reviewer workspace.

Reviewer identity is passive application-shell context rather than a button because Phase 6 does not define an account/profile action.

## Explore Acts

Explore Acts retains a dense discovery model but applies simpler service-style controls and restrained visual treatment.

**Current run** identifies the transformation being explored and **Compare with** identifies the prior run used for New/Persisting/Gone comparison.

The default view remains **Findings and processing**. **QA focus** is a distinct parallel lens rather than another finding type. **All transformed Acts** keeps Acts without findings reachable.

The QA focus lens shows, where applicable:

- provision or structural area;
- concise explanation of why it was surfaced;
- **Mandatory** or **Advisory** obligation under the active policy;
- mandatory QA state: **Not checked** or **Addressed**;
- the recorded completion outcome for addressed mandatory items;
- any resulting reviewer problem or other review consequence;
- navigation into Investigate Provision while retaining the QA-focus context.

At Act level, Explore Acts shows **Not ready / Eligible** approval eligibility together with concise counts of outstanding mandatory QA items and independent approval-blocking reviewer problems. The reviewer can open the Act-level approval summary from this context.

Advisory recommendations are optional guidance only and require no completion action. Machine findings and QA recommendations remain visibly distinct.

Search remains intentionally unspecified. Searchable fields, matching semantics, result scope and its relationship to direct provision navigation still need clarification.

### Add Acts

Corpus expansion uses the available-Acts catalogue described in the reviewer workflow specification.

The reviewer opens **Add Acts**, then:

1. searches by Act name/title and/or filters by a single year, list of years or year range;
2. may use year + Act number to locate a known Act;
3. selects one, several or all matching Acts from catalogue results showing year, Act number and title;
4. chooses **Review selected Acts**;
5. reviews the resolved selection on a confirmation screen;
6. explicitly chooses **Confirm and start processing** before retrieval/transformation begins.

Special multi-Act text syntax is not part of the preferred design.

Control inventory: `explore-acts-controls.csv`.

## Investigate Provision

The preferred screen remains an expert comparison workbench with service-style decision discipline.

The top of the screen states the task in plain language: **Compare the source and transformed provision**. It shows readable Act/provision identity, exact internal eId, processing run, arrival context, retained result position and navigation to previous/next occurrences, eISB, the rendered transformed-Act reference view and raw XML/provenance.

When the investigation was entered from a mandatory QA recommendation, a compact **Mandatory QA requirement** panel appears above the comparison. It shows why the area was surfaced, current QA state and the two explicit completion actions:

- **Checked — no further action required**;
- **Checked — review action required**.

Merely opening/viewing the provision does not complete a mandatory requirement. Either explicit action addresses the recommendation. If review action is required, the resulting observation/conclusion/problem continues through the normal review workflow; the QA recommendation itself does not remain outstanding.

The normal semantic investigation outcomes remain separate:

- Acceptable transformation;
- Source-caused issue;
- Reviewer observation only;
- Existing problem;
- New problem identified.

The source/output comparison remains compact and simultaneous. Local context may expand to the containing section or modification hierarchy. Broader generated context opens in the separate read-only rendered transformed-Act reference view.

### Investigation notebook

A full-width, resizable **Investigation notebook** sits below the comparison rather than in a side panel.

It contains working observations, comparison cases, AI suggestions, counterexamples and working hypotheses. Notebook material is exploratory and does not become a durable reviewer observation, conclusion or problem association automatically. Explicit actions such as **Record as reviewer observation** promote selected material when appropriate.

Control inventory: `investigate-provision-controls.csv`.

## Act-level approval

The preferred wireframe includes two supporting approval states.

### Not ready

The Act-level approval summary is available even when approval is blocked. It shows:

- exact Act/output/run;
- QA policy version;
- every current blocking condition;
- outstanding and addressed mandatory QA;
- approval-blocking reviewer problems;
- advisory QA guidance;
- prior QA evidence retained from earlier runs;
- direct routes back to the relevant review work.

The summary does not itself clear blockers or offer the final approval action.

### Eligible

When all current policy-defined blockers are cleared, the Act becomes **Eligible / Not approved**. The final approval step shows:

- exact Act/output/run;
- QA policy version;
- confirmation that blocking conditions are satisfied;
- remaining advisory/non-blocking context;
- optional links to rendered transformed output and source context;
- prior/reused QA evidence where relevant;
- optional approval notes;
- explicit **Approve transformed Act** action.

Eligibility does not imply that the reviewer should approve. Approval remains a named human action against the exact transformed output.

Control inventory: `act-level-qa-controls.csv`.

## Repeat-run QA evidence

Where materially changed output requires renewed QA, prior evidence remains visible as **Previously reviewed** rather than silently satisfying the new run.

The UI distinguishes:

- prior evidence retained as context;
- evidence explicitly reusable under the active policy;
- current checks that must be performed again.

The exact policy rules governing reuse remain evidence-dependent, but the presentation must make reuse explicit rather than implicit.

## Review Problem

Review Problem is a structured case-management record with restrained service-style presentation.

The main record shows:

- problem name and plain-language description;
- lifecycle progression **Identified → Backlogged → Ready for recheck → Resolved**, with **Retired** separate;
- supporting occurrences and exact reviewed locations;
- reviewer observations;
- recheck evidence;
- retained investigation thread showing how the problem understanding developed.

**Resolved** means that remediation has been rechecked by a reviewer and the problem is no longer present in the relevant transformed output. A failed recheck returns the problem to **Backlogged** with history retained.

Lifecycle and priority controls are visually separated from evidence. Identified → Backlogged remains the Phase 7 handoff.

Control inventory: `review-problem-controls.csv`.

## Intentionally unresolved mechanics

The preferred wireframe does not invent exact mechanics for cross-run identity/material equivalence, similarity signals, 1:n/n:1 trace rendering, deep-link construction, AI usefulness ranking, search behaviour, the initial QA recommendation classes, approval-blocking problem criteria, broader minimum QA evidence, or exact prior-QA reuse rules. Those remain deferred as recorded in the reviewer workflow specification and decision register.