Define and prototype the minimum recognisable Feedbacker experience

## Why this matters

Feedbacker's current direction explains its principles and infrastructure well, but it does not yet make the product experience tangible. This work should define the smallest experience that still feels recognisably like Feedbacker to an educator.

## Product hypothesis

Feedbacker is a workspace where an educator imports an assignment, rubric, and student submissions; receives criterion-by-criterion evidence, proposed marks, an overall provisional final-mark recommendation, and draft feedback; reviews every suggestion; checks consistency across the cohort; and exports the educator-approved marks and feedback.

Governance, traceability, moderation, and responsible-AI controls should support this journey rather than obscure it.

## Product rule

> Feedbacker may recommend criterion-level marks and an overall final mark, but the educator remains the sole authority who confirms and releases them.

The interface should describe any AI-proposed overall mark as a **provisional mark recommendation**. It must remain visibly distinct from the educator's confirmed final mark.

## Prototype scope

Create a clickable prototype showing one lecturer:

1. Creating an assessment and adding its rubric.
2. Importing a small set of student submissions.
3. Reviewing criterion-level evidence identified by Feedbacker.
4. Reviewing proposed observations, criterion-level marks, an overall provisional final-mark recommendation, and draft feedback.
5. Accepting, editing, or rejecting each suggestion and recording their own judgement.
6. Explicitly approving the final mark and feedback.
7. Checking that submission within a small cohort view that highlights inconsistencies, outliers, and moderation candidates.
8. Exporting the approved marks and feedback, with a record distinguishing AI suggestions from educator decisions.

## Deliverables

- A concise primary-user and job-to-be-done statement.
- A mapped happy-path journey with key decisions and system responses.
- A clickable, deliberately low-fidelity prototype.
- Clear distinctions between evidence, AI suggestions, educator judgement, and approved output.
- Clear interface treatment for provisional mark recommendations and confirmed final marks.
- A short list of excluded capabilities so this remains an MVP.
- Findings from walkthroughs with representative educators or assessment stakeholders.
- Resulting changes proposed for the product definition and backlog.

## Done when

- A lecturer can understand what Feedbacker is and what they would use it for from the prototype alone.
- The complete journey can be demonstrated using one assessment, one rubric, several submissions, a provisional final-mark recommendation, educator review, and an approved marks-and-feedback export.
- The educator can accept, edit, or reject every suggested mark and item of feedback.
- No suggested mark can become final or be released without explicit educator approval.
- Every consequential assessment decision remains visibly owned by the educator.
- The audit record clearly distinguishes what Feedbacker suggested from what the educator decided.
- The prototype demonstrates how traceability and moderation help the educator without becoming the main interface.
- The team can identify the first buildable product slice from the prototype.

No files, tests, or implementation entry points are named. Start with the product hypothesis, prototype scope, and product rule; map the lecturer journey and use the listed done criteria to check that educator decisions, provisional recommendations, moderation, traceability, and approved export are visibly distinct. Finish by identifying the first buildable product slice and excluded capabilities.

Written by the indexing model from the issue text.