# Student OS and Evidence Map: proposed connected design

**Design and implementation status · 14 September 2026. Student accounts are deferred by request.**

Implemented: shared evidence IDs, separate skill/outcome judgments, artifact-reference revision history, explicit learning reflections and a skill-use dashboard. The learner passport remains a private local log. Automated submissions, feedback notifications and enforced account access remain future work. See [Audit repairs](Audit_Repairs.md).

Keep two distinct user experiences on one shared evidence foundation. Initially maintain one codebase; avoid creating two applications that each own a different copy of the same learner evidence.

## Teacher workspace: Evidence Map

The teacher selects course outcomes, checks I-can statements and task rubrics, reviews Product / Observation / Conversation evidence, makes professional outcome judgments and prepares school-approved reporting. The teacher also reviews readiness for a particular task and plans classroom teams. Source reconciliation and moderation belong here.

## Learner workspace: Student OS

Five simple destinations:

1. **Today:** the task, success criteria and the next action.
2. **My skills:** what I have demonstrated, where the evidence is and what I should practise.
3. **My evidence:** saved work references, claims and submission/review status.
4. **Feedback:** specific teacher comments, a response and a changed attempt.
5. **Goals:** a short goal, a practice plan and a review date.

The current teacher-managed profile and standalone passport are prototypes of parts of this experience. Automated submissions, feedback notifications and authenticated learner access still need implementation.

## Shared data model

| Record | Essential fields | Ownership / rule |
|---|---|---|
| Learner and course membership | stable learner ID, course/section ID, active dates | School/teacher controlled; preserve IDs when rosters change |
| Outcome | stable ID, official wording, source edition/page, review status | Verified curriculum; historical crosswalk separate |
| Skill | stable ID, observable description, descriptors, course/domain | Versioned; proposed outcome links are reviewed explicitly |
| Task / attempt | task ID, brief version, learner, date, context | Distinguish baseline, practice and changed retest |
| Evidence | stable ID, attempt, learner/course, method, artifact reference, observed detail, conditions | One record of what happened; corrections retain history |
| Claim | evidence ID, learner reflection/self-rating, submitted date | Learner-authored; never automatically teacher-verified |
| Review | evidence ID, teacher, verification decision, feedback, date | Teacher-authored; distinguish verified evidence from achievement judgment |
| Judgment | target outcome or skill, rubric version, level, linked evidence IDs, teacher rationale, date | Different targets can produce different warranted judgments |
| Readiness review | domain/task context, criterion profile, current support decision, review date, evidence IDs | Private teacher planning information; no permanent cross-course rank |
| Team plan | course/task, reviewed membership/seats, role routine, review note | Private source record; student export excludes private fields |

A single artifact may contain several evidence events. A PSD alone does not prove the process was independent: an observation or explanation can provide additional evidence linked to the same attempt. Several evidence events can support one judgment; one evidence event can support more than one explicitly reviewed target.

## Example, using fictional data

Learner DEMO-1 completes PS-A and saves `poster.psd`. Evidence E-101 records the inspected layer structure; E-102 records an observed mask repair; E-103 records the learner’s explanation. A teacher reviews E-102 and E-103 for the masking skill. Separately, the teacher determines whether E-101 through E-103 address the selected, verified course outcome and task rubric. The student sees feedback and a next practice goal. The teacher sees the outcome evidence and a private readiness review. The artifact is not copied into two unrelated systems.

## Kagan-informed classroom use

Use positive interdependence, individual accountability, equitable opportunities to participate and simultaneous participation to design the activity. Seat/turn numbers organise participation. Criterion scores describe performance. Readiness reviews help the teacher plan support. They are separate concepts.

Retain domain-specific evidence, rotate roles and use individual checks after teamwork. Do not assign a single permanent rank or fixed learning-style category. A learner’s own progress display can show criterion-level feedback and growth without exposing classmates’ private readiness information.

## First implementation slice

After fixing persistence and reconciling the selected outcome, connect **one task, one learner, one skill and one outcome** through a canonical evidence ID. Display that same evidence in both teacher views. Keep the old records read-only during an explicitly reviewed migration. Add a correction path and traceable backup round-trip before broad migration.

Acceptance examples:

- Editing an artifact reference once updates both views without changing prior judgments.
- A learner self-rating never changes a teacher outcome level.
- A teacher can link evidence to a skill while leaving the outcome judgment unresolved.
- An incorrect mapping can be corrected while retaining the original mapping and its history.
- Deleting or withdrawing a claim does not silently erase a teacher’s historical judgment.
- Full backup and restore retain shared IDs, memberships, versions and review history.

Before opening a true student portal, enforce identity and role checks on the server. A learner must never receive other students’ records or teacher-private fields. Define retention, correction, export and backup responsibilities with the school. Use the existing classroom submission channel during the local pilot.