Skip to main content

Milestone delivery and advisor review

This page goes one level deeper into the delivery phase of Academia after a proposal has already become an active project. It documents how milestone work moves from student upload to advisor review, revision, approval, and the unlocking of the next milestone.

:::tip Use this page when You need the real milestone loop: upload, feedback, resubmission, approval, and sequential progress control. :::

Fastest route through this guide​

  • Start with End-to-end sequence if you want the short operational flow.
  • Jump to Step 4 if you care most about the stepwise lock rule.
  • Jump to Student-side milestone state model or Advisor-side review state model if you are documenting UI behavior.

Why this phase matters​

Milestones are where approved projects turn into supervised academic progress.

This phase decides:

  • whether a student group has submitted the current required deliverable
  • whether the advisor is still reviewing or has already responded
  • whether the group must revise and resubmit
  • whether the milestone is complete and the next one can begin
  • whether project progress should advance on the dashboard

Roles in this phase​

RoleResponsibility in milestone delivery
Student group leaderUploads the first deliverable version and later resubmits after feedback
Student group membersTrack milestone state, feedback, approval, and next due work
AdvisorReviews the latest submission, adds feedback, attaches review notes, and approves the final version
CoordinatorMonitors project progress, advisor workload, and department execution health
Department headOversees department-wide progress and can monitor stalled projects

Best page after this one​

If you want to continue into...Open this page
evaluator scoring and defense preparationEvaluation and defense workflow
staff monitoring of assignment and late-stage readinessStaff oversight and assignment
the role-based view of the same platformRoles and dashboards

End-to-end sequence​

The current product flow is best understood as seven steps:

  1. The project receives a milestone timeline from its selected template.
  2. Student opens the milestone dashboard and sees the next available step.
  3. Student uploads the first deliverable file.
  4. Advisor receives the submission in the review queue.
  5. Advisor adds feedback, with or without an attachment.
  6. Student resubmits if revision is needed.
  7. Advisor approves the final submission and unlocks the next milestone.

Step 1: Project receives a milestone timeline​

Milestone delivery starts only after the proposal has already been approved and turned into a project.

Current rules​

  • milestones are generated from the project's assigned milestone template
  • due dates are computed from project creation time plus the template durations
  • most projects follow a sequential template
  • the default department flow already includes stages such as proposal, SRS, SDD, implementation, and final defense

Backend behavior​

  • project creation can apply a milestone template automatically
  • milestone records are created immediately for the project
  • each milestone carries sequence, title, due date, and status
  • backend enforces stepwise progression for template-based projects

Why this matters​

Students do not invent milestones manually. They work inside a department-defined academic schedule.

Step 2: Student opens the milestone dashboard​

The student side uses the approved proposal plus linked project as the main source of truth.

What the frontend shows​

The student dashboard and milestone pages already render:

  • milestone title
  • due date
  • current status
  • latest submitted file name
  • latest feedback preview
  • approval metadata when available

Main student pages involved​

  • milestone overview page
  • submissions page
  • upload document page for the selected milestone

Important state labels​

The student UI already centers on these milestone states:

  • Upload Submission
  • Awaiting Advisor Review
  • Feedback Received
  • Resubmit
  • Approved

Placeholder visual​

Student milestones placeholder

Step 3: Student uploads the first deliverable​

When the milestone is open and allowed, the group uploads the first version of its deliverable.

Submission endpoint​

  • POST /projects/milestones/:milestoneId/submissions

Current file rules​

  • used for both first submission and resubmission
  • request type is multipart/form-data
  • file is required
  • supported file types are PDF and DOCX

Frontend behavior​

The upload page resolves the current milestone, checks whether the action is allowed, and then uploads against the current milestone id.

What happens on success​

  • a new submission record is created
  • milestone state becomes SUBMITTED
  • student dashboard refetches milestone data
  • advisor can now see the item in the review queue

Step 4: Stepwise rule controls what can be submitted next​

Milestones are not independent dropboxes.

Sequential rule​

For template-based projects, milestone #N cannot move to SUBMITTED or APPROVED until all earlier milestones are already APPROVED.

Practical frontend behavior​

  • if a previous milestone is still pending, the next upload action stays locked
  • if a previous milestone is awaiting review, later milestones remain blocked
  • the student upload page redirects back to milestones when a prerequisite is not satisfied

Why this matters​

This keeps the project aligned with academic supervision instead of allowing groups to skip required checkpoints.

Step 5: Advisor reviews the submitted work​

Once a submission exists, the advisor becomes the primary owner of the next action.

Main advisor queue endpoint​

  • GET /projects/advisors/me/milestone-review-queue

What the review queue returns​

Each queue item includes:

  • active project details
  • group details
  • milestone details
  • latest submitted file
  • feedback count
  • latest feedback preview if review already started

Advisor dashboard behavior​

The advisor dashboard already treats milestone review as a queue of items waiting for action.

Recommended advisor screen states from the backend guides are:

  • Review Submission
  • Continue Review
  • Feedback Sent
  • Approve Submission
  • Approved

Placeholder visual​

Advisor review placeholder

Step 6: Advisor gives feedback and may attach review notes​

Review does not have to jump straight from submitted to approved.

Feedback endpoint​

  • POST /projects/milestones/:milestoneId/submissions/:submissionId/feedbacks

Current feedback rules​

  • feedback message is required
  • advisor can attach an optional PDF or DOCX review file
  • feedback history can be read back for the same submission

Feedback history endpoint​

  • GET /projects/milestones/:milestoneId/submissions/:submissionId/feedbacks

What students see after feedback​

  • latest feedback preview on the milestone card
  • feedback comments on the submissions page
  • advisor attachment links when a review file exists
  • Feedback Received state that re-enables submission

Practical effect​

The platform turns revision into a visible loop instead of private side-channel communication.

Step 7: Student resubmits after revision​

Resubmission uses the same milestone submission endpoint as the first upload.

Current resubmission rule​

Student can resubmit when:

  • a latest submission already exists
  • feedback exists on that submission
  • the milestone is not yet approved

Student cannot resubmit when​

  • the milestone is already approved
  • the latest submission is still awaiting advisor review with no feedback yet

Frontend behavior​

The student milestone and upload pages already distinguish between:

  • first upload
  • waiting for review
  • feedback received
  • resubmit allowed

Placeholder visual​

Student submission placeholder

Step 8: Advisor approves the final submission​

Approval is the final decision in the milestone loop.

Approval endpoint​

  • PUT /projects/milestones/:milestoneId/submissions/:submissionId/approve

What approval does​

When approval succeeds:

  1. the latest submission becomes APPROVED
  2. the milestone becomes APPROVED
  3. students receive milestone approval notification
  4. the next milestone in the sequence can proceed
  5. project progress updates on student and advisor dashboards

Queue behavior after approval​

Approved items should disappear from the advisor review queue after the next refresh, because the queue is only for milestones still waiting for review.

Student-side milestone state model​

The student experience is easiest to understand in four concrete states.

State A: No submission yet​

  • no submission exists
  • main action: Upload Submission

State B: Submission exists and is awaiting review​

  • latest submission exists
  • no feedback yet
  • milestone not approved
  • main actions: View Submission
  • status label: Awaiting Advisor Review

State C: Feedback exists and revision is required​

  • latest submission exists
  • feedback exists
  • milestone not approved
  • main actions: View Feedback, Resubmit
  • optional action: Open Advisor Attachment

State D: Milestone approved​

  • milestone or latest submission is approved
  • upload actions stop
  • main actions: View Submission, View Feedback
  • status label: Approved

Advisor-side review state model​

The advisor queue also has a clear operating model.

State A: First review pending​

  • milestone status is SUBMITTED
  • feedback count is 0
  • main actions: Review Submission, Add Feedback, Approve

State B: Review already started​

  • milestone status is SUBMITTED
  • feedback count is greater than 0
  • main actions: Continue Review, Add More Feedback, Approve

State C: Submission approved​

  • latest submission or milestone is APPROVED
  • item should no longer stay in the active queue

Progress and notifications in this phase​

Milestone review changes the rest of the project lifecycle in real time.

Student progress impact​

  • approved milestone count increases
  • overall project progress percentage changes
  • the next deadline label can move forward

Notification impact​

The backend guides already expect milestone-driven notifications such as milestone approval so the frontend can refresh cards, progress, and unlocked actions.

Role-by-role view of this phase​

Student group leader​

  • opens the current milestone
  • uploads the required deliverable
  • reads advisor feedback
  • resubmits when revision is requested

Student group members​

  • monitor milestone progress
  • see whether the team is blocked, under review, or approved

Advisor​

  • opens the review queue
  • inspects the latest submitted file
  • gives actionable feedback
  • approves the final version

Coordinator​

  • monitors whether active projects are moving or stalling
  • uses project and department dashboards for workload visibility

Department head​

  • keeps oversight on department-wide completion quality and progression

Where this phase leads next​

Once several milestones are approved and the project reaches late-stage readiness, the workflow moves into evaluation and defense preparation.

That next phase includes:

  • evaluator assignment and scoring flow
  • defense schedule visibility
  • readiness checks for final presentation and reporting

Best next reads​