Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/AngelZurita28/VeranoRegional/llms.txt

Use this file to discover all available pages before exploring further.

Once the application window closes, the administrator runs the automated allocation algorithm to assign each eligible student to a research project. The process is fully automated: it reads all applications for the active summer period, scores and ranks students, then works through each student’s priority list to find the first project they qualify for that still has open slots.
Allocation is irreversible. Once the administrator triggers run_allocation_process, the assignments are written to the database and cannot be undone through the platform interface. Confirm that the application window has closed and all data is correct before running the algorithm.

​
Algorithm inputs

InputSourceDescription
noteAverageStudent profileGPA on a base-100 scale
studentProgressStudent profile (careerProgressPercentage)Percentage of degree completed (integer)
projectRequirementProject field (careerProgressPercentage)Minimum progress a student must have to qualify
projectCapacityProject field (studentAmount)Maximum number of students the project can accept
priorityApplication recordStudent’s personal ranking (1 = highest preference)
applicationDateApplication record (createDate)Timestamp of the priority-1 application, used as a tiebreaker

​
Step-by-step algorithm

1

Load all applications

The algorithm fetches every application for the active summer period, including each student’s GPA, career progress, and the capacity and requirement of the applied project.
2

Group by student

Applications are grouped by student user ID. Each student entry holds their academic details and the ordered list of projects they applied to.
3

Sort students by GPA and date

Students are sorted in descending order of noteAverage (higher GPA is processed first). When two students have the same GPA, the one whose priority-1 application was submitted earlier is processed first (ascending createDate).
4

Iterate in priority order for each student

For each student, the algorithm iterates through their applications sorted by priority (ascending). For each application it checks two conditions:
  • Meets requirement: studentProgress >= projectRequirement
  • Has slots: the number of students already assigned to the project is less than projectCapacity
If both conditions are true, the student is assigned to that project and the loop moves to the next student. If the conditions fail, the algorithm moves to the student’s next-priority application.
5

Record accepted applications

All application IDs that resulted in an assignment are collected and updated in a single UPDATE ... WHERE id IN (...) query that sets isAccepted = 1 for those records.

​
Algorithm output

After the process completes, the platform returns a JSON summary: 
{
  "status": "success",
  "summary": {
    "totalStudents": 120,
    "assignedStudents": 98
  }
}
totalStudents is the number of distinct students who had at least one application. assignedStudents is the number of students who were successfully matched to a project.

​
Unassigned students

A student remains unassigned if none of their applied projects had open slots, or if their career progress percentage did not meet the minimum requirement of any project they applied to. Unassigned students do not receive an accepted application and cannot upload a final report.
Only the administrator (role 1) can trigger the allocation process. Coordinators and researchers cannot initiate allocation from their dashboards.

Build docs developers (and LLMs) love

Get started for freeTalk to us