Skip to main content

Evaluation and defense workflow

This page goes one level deeper into the late-stage workflow of Academia after milestone progress has already moved a project toward completion. It documents how evaluator assignment, scoring work, defense schedule visibility, and student defense readiness fit together.

:::tip Use this page when You need the late-stage flow from evaluator assignment through scoring, defense scheduling, and student readiness. :::

Fastest route through this guide​

  • Start with End-to-end sequence if you want the shortest late-stage summary.
  • Jump to Step 5 if you care most about the evaluator scoring form.
  • Jump to Evaluator-side state model if you are mapping pending, in-progress, submitted, and reviewed states.

Why this phase matters​

This is the stage where a project stops being only a supervised build process and becomes a formally reviewed academic outcome.

This phase decides:

  • which evaluators are assigned to review a project
  • which projects are ready for evaluator scoring
  • how evaluators move through pending, in-progress, submitted, and reviewed work
  • how defense sessions appear on evaluator and student schedules
  • how students prepare final materials before the session

Roles in this phase​

RoleResponsibility in evaluation and defense
CoordinatorAssigns evaluators, monitors evaluation progress, and tracks defense readiness
Department headOversees assignment quality, policy compliance, and late-stage completion health
AdvisorPrepares the project for review readiness and supports defense preparation
EvaluatorReviews assigned projects, scores them with rubric criteria, and participates in defense sessions
Student groupPrepares defense materials, tracks readiness, and appears for the scheduled defense

Best page after this one​

If you want to continue into...Open this page
coordinator and department-head control of assignment and readinessStaff oversight and assignment
the full workflow from first setup to defenseProject lifecycle
the role view for evaluators and department staffRoles and dashboards

End-to-end sequence​

The current product direction is best understood as seven steps:

  1. Project reaches late-stage readiness after milestone progress.
  2. Coordinator or department head assigns evaluators to the project.
  3. Evaluator sees the project in assigned-project and evaluation views.
  4. Evaluator opens the scoring form and works through the rubric.
  5. Defense sessions appear in evaluator schedule and student defense pages.
  6. Student group completes readiness items and materials.
  7. Evaluation records move toward submitted or reviewed status after the session.

Step 1: Project reaches evaluation readiness​

Evaluation starts only after a project has advanced beyond early milestone delivery.

What readiness means in practice​

  • the project already exists as an active approved record
  • milestone progress is far enough along to justify evaluator involvement
  • advisor and department staff can see project state, members, and progress
  • defense-related information becomes relevant on late-stage pages

Current evidence in the product​

The evaluator and assigned-project screens already assume each evaluation item has:

  • project title
  • group name
  • advisor information
  • milestone progress
  • defense date and room
  • evaluation status

This means the product treats evaluation as a project-stage workflow, not an isolated grading form.

Step 2: Coordinator or department head assigns evaluators​

Evaluator assignment is a staff-owned operation.

Main backend endpoints​

  • GET /projects/:id/evaluators
  • GET /projects/:id/evaluators/eligible
  • PUT /projects/:id/evaluators
  • DELETE /projects/:id/evaluators/:evaluatorUserId

Access rules​

  • assignment and reassignment are owned by DEPARTMENT_HEAD and COORDINATOR
  • eligible evaluator lookup excludes already assigned evaluator users and the current advisor

Why this matters​

The platform separates supervision from final review. The advisor is not the same actor as the evaluator assignment list.

Step 3: Evaluator receives assigned project context​

Once assigned, the evaluator dashboard becomes the main working surface.

Main evaluator routes in the frontend​

  • /dashboard/evaluator
  • /dashboard/evaluator/assigned-projects
  • /dashboard/evaluator/evaluations
  • /dashboard/evaluator/evaluations/:id
  • /dashboard/evaluator/schedule

What the evaluator dashboard already emphasizes​

  • assigned projects
  • evaluation pipeline
  • upcoming defense sessions
  • due dates for scoring work
  • final score visibility for completed reviews

Evaluation statuses already present in the UI​

  • pending
  • in_progress
  • submitted
  • reviewed

Placeholder visual​

Evaluator workflow placeholder

Step 4: Evaluator reviews assigned projects before scoring​

The evaluator does not score blind. The assigned-project view already presents supporting context before the scoring form opens.

What the assigned-project view includes​

  • project title and description
  • group name and member list
  • advisor contact context
  • progress percentage
  • document count
  • milestone completion summary
  • defense date and room

Why this matters​

This page works as the evaluator's pre-scoring workspace. It gives enough context to decide whether the project is ready for detailed assessment and which documents need review first.

Step 5: Evaluator opens the scoring form​

The detailed evaluation page is the main scoring workspace.

What the evaluation detail page shows​

  • project title
  • group members
  • advisor name
  • defense date and venue
  • project description
  • rubric categories
  • score totals and completion percentage
  • overall evaluator comments

Current scoring behavior in the frontend​

The evaluation detail screen already enforces core reviewer behavior:

  • all rubric categories must be scored before final submission
  • overall comments are required before submission
  • reviewed items are treated as read-only

Rubric model already visible in the UI​

Current evaluation records use weighted categories such as:

  • technical quality
  • presentation
  • documentation
  • innovation and impact

Practical state model​

  • pending: evaluator has not started scoring yet
  • in_progress: evaluator has begun scoring but not finalized
  • submitted: evaluator has sent scoring output
  • reviewed: final reviewed record remains visible but is no longer editable

Step 6: Defense sessions become the time anchor for evaluation​

The defense schedule is not separate from evaluation. It is the time anchor around which evaluator work is organized.

Main evaluator schedule route​

  • /dashboard/evaluator/schedule

What the schedule screen already shows​

  • upcoming and completed defense sessions
  • project title and group name
  • date and time
  • room and building
  • advisor
  • evaluator panel list
  • evaluation status tied to each session

Common schedule-oriented states​

  • upcoming defense session
  • completed defense session
  • evaluation still pending after session
  • evaluation already submitted or reviewed

Practical use​

The evaluator schedule page connects logistics and assessment in one place. Evaluators can move from the scheduled session directly into preparation or scoring actions.

Step 7: Student tracks defense readiness​

On the student side, the final stage is exposed as a defense preparation surface rather than a scoring surface.

Main student route​

  • /dashboard/student/defense

What the student defense page already shows​

  • scheduled venue information
  • readiness progress percentage
  • checklist completion tracking
  • defense materials
  • feedback and reply interactions around preparation items

Why this matters​

Students experience the late stage differently from evaluators. They need operational readiness, not rubric management.

Placeholder visual​

Defense readiness placeholder

Step 8: Defense session and evaluation output converge​

The defense itself is where schedule, rubric, and readiness converge.

What happens around the session​

  • evaluators arrive with project context and rubric state
  • students arrive with completed materials and readiness items
  • the session takes place at a specific time and venue
  • evaluations move toward submitted or reviewed status after the session

Current product direction​

The frontend already treats each evaluation record as tied to defense metadata such as:

  • defense date
  • defense room
  • assigned advisor
  • project members
  • total score

That means the system is designed to treat evaluation and defense as one continuous final-stage workflow.

Evaluator-side state model​

The evaluator experience is easiest to understand through four working states.

State A: Pending​

  • evaluator is assigned
  • no meaningful rubric progress yet
  • main action: Start

State B: In progress​

  • evaluator has begun scoring
  • rubric is partially filled
  • main action: Continue

State C: Submitted​

  • evaluator has submitted the score record
  • item remains visible as completed evaluator output
  • main action: View

State D: Reviewed​

  • evaluation is finalized and treated as a completed record
  • score stays visible for reporting and reference
  • main action: View

Student-side defense readiness model​

The student defense page is closer to a readiness checklist than a scoring form.

State A: Preparing​

  • checklist items are still incomplete
  • materials may still be under preparation
  • readiness progress is below full completion

State B: Near ready​

  • most checklist items are completed
  • materials are largely prepared
  • student uses the page to confirm missing final details

State C: Ready for session​

  • readiness items are complete
  • student can focus on appearance at the scheduled defense

Coordinator and department oversight in this phase​

Although the evaluator and student views are the most visible, staff still own the overall orchestration.

Coordinator responsibilities​

  • assign evaluators to the right projects
  • monitor whether evaluation work is still pending or already submitted
  • track defense readiness and scheduling load

Department head responsibilities​

  • oversee whether the department is finishing projects cleanly
  • intervene when evaluator assignment or final-stage progress stalls

Where this phase leads next​

After this stage, the remaining documentation opportunity is not another student-facing workflow step. It is the staff orchestration layer around assignment quality, reports, and department-wide monitoring.

That next move includes:

  • coordinator and department-head oversight flows
  • assignment and readiness reporting views
  • operational dashboards for late-stage monitoring

That layer is now covered in Staff oversight and assignment.

Best next reads​

  • Open Staff oversight and assignment if you want the staff-side operational controls that sit above evaluator and defense activity.
  • Open Project lifecycle if you want to return to the full workflow map after reading the late-stage deep dive.