Keyboard shortcuts

Press or to navigate between chapters

Press S or / to search in the book

Press ? to show this help

Press Esc to hide this help

End-to-End Workflow

This chapter walks through a complete semester lifecycle, showing how all the components from previous chapters work together in practice.

Reading Guide

Each phase below shows the Goal, Key Actions, and Technical Flow for that stage of the semester. Follow the phases sequentially to understand how registration flows into grading, which then feeds into eligibility and exam registration.

Phase 0: Semester Setup

Setup Phase

At the start of the semester, staff configures the basic teaching structure.

Staff Actions:

ActionDetails
Create LectureSet up the lecture record (e.g., "Linear Algebra WS 2024/25")
Create TutorialsDefine tutorial groups with times, locations, and capacities
(Optional) Create TalksFor seminars, define talk slots for student presentations

Phase 1: Tutorial/Talk Registration Campaign

Goal

Assign students to tutorial groups or seminar talks

Staff Actions:

ActionDetails
Create CampaignStaff creates a Registration::Campaign for the lecture
Set ModeChoose allocation_mode: first_come_first_served or preference_based
Add ItemsCreate one Registration::Item for each tutorial or talk
Attach PoliciesAdd Registration::Policy records (e.g., institutional_email, prerequisite_campaign)
Open CampaignMake available for student registrations (registration requests)

Student Experience:

Two Registration Modes

  • FCFS Mode: Visit page, check eligibility, register if eligible (immediate confirmation/rejection)
  • Preference Mode: Visit page, check eligibility, rank options if eligible, wait for allocation

Technical Flow:

  • Eligibility check via Campaign#evaluate_policies_for happens when user visits the campaign page
  • Ineligible users see an error message explaining the reason
  • Eligible users see the registration interface (register buttons for FCFS, preference form for preference-based)
  • Each registration request creates a Registration::UserRegistration with status pending (preference-based) or confirmed/rejected (FCFS)
  • Registration::PolicyEngine evaluates all active policies in order during the initial eligibility check

Phase 2: Preference-Based Allocation (if applicable)

Goal

Compute optimal assignment respecting preferences and constraints

Only for Preference-Based Campaigns

This phase is skipped if the campaign uses first_come_first_served mode.

Staff Actions:

  • At or after registration deadline, staff triggers campaign.allocate_and_finalize!
  • Campaign status transitions: openclosedprocessingcompleted

Technical Details:

AspectImplementation
ServiceRegistration::AllocationService delegates to solver (e.g., Min-Cost Flow)
Cost ModelPreferences treated as costs (rank 1 = cost 1, rank 2 = cost 2, etc.)
ConstraintsRespects capacity from Registerable#capacity
OutputOne confirmed UserRegistration per user, rejects others
IdempotencyOperation can be re-run if needed with same results

Phase 3: Allocation Materialization

Goal

Apply confirmed registrations to domain model rosters

Staff Actions:

  • Staff calls campaign.finalize!
  • Registration::AllocationMaterializer iterates through all Registration::Item records
  • For each item, collects confirmed user IDs and calls registerable.materialize_allocation!(user_ids:, campaign:)

Domain Effects:

ModelEffect
TutorialStudent rosters updated
TalkSpeaker assignments updated
ExamBefore writing roster, eligibility is revalidated; ineligible users are excluded
AuthorityRosters are now the authoritative source for course operations
IdempotencySame inputs produce same results (can be re-run safely)

Phase 4: Post-Allocation Roster Maintenance

Goal

Handle late registrations, drops, and moves

Staff Operations via Roster::MaintenanceService:

OperationMethodPurpose
Transfermove_user!(from:, to:)Move student between tutorials
Addadd_user!(to:)Add late arrival
Removeremove_user!(from:)Remove dropout

Guardrails

  • Service enforces capacity limits (unless allow_overfill: true)
  • All operations are transactional (atomic)
  • Changes are logged for audit trail
  • Operates on domain rosters directly, independent of campaign

Phase 5: Coursework Assessments & Grading

Goal

Track student performance on assignments and presentations

Setup Flow:

StepAction
1. Create AssessmentFor each Assignment, create linked Assessment::Assessment with requires_points: true
2. Seed ParticipationsCall assessment.seed_participations_from!(user_ids: tutorial.roster_user_ids)
3. Define TasksCreate Assessment::Task records for each problem/component
4. Student SubmissionStudents upload Submission records (possibly as teams)
5. GradingTutors grade via Assessment::SubmissionGrader

Grading Flow:

Team Grading Fan-Out

Service creates Assessment::TaskPoint for each team member automatically. Points are validated against Task#max_points, and Participation#points_total is recomputed automatically.

Publication:

  • Staff publishes results by setting assessment.results_published = true

For Talks (Simplified):

AspectDifference
Moderequires_points: false (grade-only mode)
SeedingSeed from talk speaker roster
GradingRecord final grade_value directly on Assessment::Participation

Phase 6: Achievement Tracking

Goal

Record qualitative accomplishments for eligibility

Staff Actions:

  • Staff creates Achievement records for students
  • Examples: blackboard_presentation, class_participation, peer_review
  • These augment quantitative points for eligibility determination

Phase 7: Student Performance Materialization

Goal

Materialize student performance facts for all lecture students.

Scope

Performance data is computed for all students enrolled in the lecture (e.g., 150 students), not just those who plan to register. This provides transparency and legal compliance: every student can verify their eligibility status.

Staff Configuration:

  • Staff configures the StudentPerformance::Rule for the lecture (minimum points, required achievements, etc.).
  • A background job runs StudentPerformance::Service.compute_and_upsert_all_records!(lecture), which populates or updates the StudentPerformance::Record for every student in the lecture.

Materialized Data in StudentPerformance::Record:

FieldContent
points_totalSum of relevant coursework points earned so far.
achievements_metA set of Achievement IDs the student has earned.
computed_atTimestamp of last factual recomputation.
rule_idForeign key to the StudentPerformance::Rule used.

Factual Data Only

The Record stores only raw factual data (points, achievements). It does NOT store eligibility status or interpretations. Those are determined later during teacher certification.

Staff Actions:

  • Staff reviews the materialized records to verify correctness
  • Staff can trigger manual recomputation if needed
  • Records are ready for teacher certification (next phase)

Staff Actions:

  • Staff reviews the materialized records to verify correctness
  • Staff can trigger manual recomputation if needed
  • Records are ready for teacher certification (next phase)

Phase 8: Teacher Certification

Goal

Teachers review materialized performance data and certify eligibility decisions for all students.

The Certification Step

This is where human judgment enters the process. Teachers use the StudentPerformance::Evaluator to generate eligibility proposals, then review and certify them, creating persistent StudentPerformance::Certification records.

Staff Workflow:

StepActionTechnical Detail
1. Generate ProposalsStaff triggers StudentPerformance::Evaluator.bulk_proposals(lecture)Creates proposals for all students based on Record + Rule
2. Review ProposalsStaff reviews the Certification DashboardShows proposed status (passed/failed) for each student
3. Bulk AcceptStaff clicks "Accept All Proposals" (common case)Creates Certification records with status: :passed or :failed
4. Manual OverridesFor exceptional cases, staff manually overrides individual certificationsSets custom status with required note field
5. Verify CompletenessSystem checks all lecture students have certificationsRequired before campaigns can open

Certification Data (StudentPerformance::Certification):

FieldContent
user_idForeign key to student
lecture_idForeign key to lecture
record_idForeign key to the performance Record (optional)
rule_idForeign key to Rule used (optional, for audit)
statusEnum: passed, failed, or pending
noteTeacher's note (required for manual overrides)
certified_atTimestamp of certification
certified_by_idForeign key to teacher who certified

Pending Status

Certifications with status: :pending are considered incomplete. Campaigns cannot open or finalize until all certifications are resolved to passed or failed.

Rule Change Handling:

Rule Updates After Certification

If staff modifies the StudentPerformance::Rule after certifications exist:

  • System shows a "Rule Changed" warning
  • Staff can view diff: "12 students would change: failed → passed"
  • Staff must review and re-certify affected students
  • System marks old certifications as stale

Recomputation Triggers:

TriggerEffect
Grade ChangeRecord recomputed, Certification marked for review
Achievement AddedRecord recomputed, Certification marked for review
Rule ModifiedAll certifications marked for review

Phase 9: Exam Registration Campaign

Goal

Allow eligible students to register for the exam (FCFS).

Complete Exam Documentation

For full details on the Exam model, see Exam Model.

Campaign Setup:

StepAction
1. Create ExamStaff creates the Exam record with date, location, and capacity.
2. Create CampaignStaff creates a Registration::Campaign for the exam.
3. Attach PolicyAdd a Registration::Policy with kind: :student_performance.
4. Optional PoliciesMay also attach other policies (e.g., institutional_email).
5. OpenThe campaign opens for registrations.

Phase 9: Exam Registration Campaign

Goal

Allow eligible students to register for the exam (FCFS).

Complete Exam Documentation

For full details on the Exam model, see Exam Model.

Pre-Flight Checks:

Campaign Cannot Open Without Complete Certifications

Before staff can transition a campaign to open status:

  1. System verifies all lecture students have StudentPerformance::Certification records
  2. All certifications must have status: :passed or :failed (no pending)
  3. If checks fail, campaign opening is blocked with clear error message

Campaign Setup:

StepAction
1. Create ExamStaff creates the Exam record with date, location, and capacity.
2. Create CampaignStaff creates a Registration::Campaign for the exam.
3. Attach PolicyAdd a Registration::Policy with kind: :student_performance, phase: :registration.
4. Optional PoliciesMay also attach other policies (e.g., institutional_email).
5. Pre-Flight CheckSystem validates certification completeness.
6. OpenThe campaign opens for registrations (only if pre-flight passes).

Student Experience:

  • Students see their eligibility status based on their Certification.status
  • Only students with status: :passed certifications can successfully register
  • Registration is first-come-first-served until capacity is reached
  • Students receive immediate confirmation or rejection with a reason

Registration Flow:

graph LR
    A[Student Attempts Registration] --> B[PolicyEngine Evaluates]
    B --> C{Student Performance Policy}
    C --> D[Lookup Certification]
    D --> E{Certification.status}
    E -->|:passed| F[Continue to next policy]
    E -->|:failed| G[Reject: Not eligible]
    E -->|:pending| H[Reject: Certification incomplete]
    F --> I[All Policies Pass]
    I --> J[Confirm Registration]

No Runtime Recomputation

Unlike the old approach, the registration flow does NOT trigger any recomputation. It simply looks up the pre-existing Certification record and checks its status. This ensures consistency and prevents race conditions.

After Registration Phase:

  • Campaign remains open while students register
  • When registration deadline is reached, staff calls campaign.close!
  • Campaign transitions to processing status
  • Staff then proceeds to finalization (Phase 10)

After Registration Phase:

  • Campaign remains open while students register
  • When registration deadline is reached, staff calls campaign.close!
  • Campaign transitions to processing status
  • Staff then proceeds to finalization (Phase 10)

Phase 10: Exam Registration Finalization

Goal

Materialize confirmed exam registrations to the exam roster.

Pre-Finalization Checks:

Finalization Requires Complete Certifications

Before staff can finalize the campaign:

  1. System re-validates that all lecture students have certifications
  2. All certifications must still be passed or failed (no pending)
  3. System checks if any certifications are marked as stale (due to rule changes or record updates)
  4. If any issues exist, finalization is blocked with a remediation prompt

Remediation Workflow:

IssueResolution
Pending CertificationsStaff must resolve to passed or failed
Stale CertificationsStaff must review and re-certify affected students
Missing CertificationsSystem auto-generates proposals, staff must certify

Finalization Process:

StepAction
1. ValidationSystem runs pre-finalization checks
2. Eligibility FilterOnly confirmed registrants with Certification.status: :passed are included
3. MaterializationCalls exam.materialize_allocation!(user_ids:, campaign:)
4. Status UpdateCampaign transitions to completed

Post-Finalization State:

  • Exam Roster now contains subset of eligible students who registered (e.g., 85 of 126 eligible)
  • Staff views Exam Roster screen to manage participants
  • Roster is ready for exam administration (room assignments, grading)

Two Distinct Lists

  • Certification Dashboard (Phase 8): All 150 lecture students with eligibility status
  • Exam Roster (Phase 10+): Only 85 registered students who will take the exam

The roster is used for exam administration, while certifications remain for audit/legal purposes.


Phase 11: Exam Grading & Grade Schemes

Goal

Record exam scores and assign final grades

Grading Setup:

StepAction
1. Create AssessmentAfter exam is administered, create Assessment::Assessment for the exam
2. Seed ParticipationsFrom confirmed exam registrants
3. Define TasksCreate Assessment::Task records for each exam problem
4. Enter PointsTutors enter points via grading interface
5. AggregatePoints aggregate to Participation#points_total

Grade Scheme Application:

Converting Points to Grades

Staff analyzes score distribution (histogram, percentiles), then creates and applies a GradeScheme::Scheme.

StepProcess
AnalyzeView distribution statistics and histogram
ConfigureCreate GradeScheme::Scheme with absolute point bands or percentage cutoffs
ApplyCall GradeScheme::Applier.apply!(scheme)
ResultService computes grade_value for each participation based on points
OverrideManual adjustments possible for exceptional cases

Multiple Choice Exam Extension

For exams with multiple choice components requiring legal compliance, see the Multiple Choice Exams chapter for the two-stage grading workflow.

Final Result:

  • Students have both granular points (TaskPoint records) and final grade (Participation#grade_value)

Phase 11: Exam Grading & Grade Schemes

Goal

Record exam scores and assign final grades

Grading Setup:

StepAction
1. Create AssessmentAfter exam is administered, create Assessment::Assessment for the exam
2. Seed ParticipationsFrom confirmed exam registrants
3. Define TasksCreate Assessment::Task records for each exam problem
4. Enter PointsTutors enter points via grading interface
5. AggregatePoints aggregate to Participation#points_total

Grade Scheme Application:

Converting Points to Grades

Staff analyzes score distribution (histogram, percentiles), then creates and applies a GradeScheme::Scheme.

StepProcess
AnalyzeView distribution statistics and histogram
ConfigureCreate GradeScheme::Scheme with absolute point bands or percentage cutoffs
ApplyCall GradeScheme::Applier.apply!(scheme)
ResultService computes grade_value for each participation based on points
OverrideManual adjustments possible for exceptional cases

Multiple Choice Exam Extension

For exams with multiple choice components requiring legal compliance, see the Multiple Choice Exams chapter for the two-stage grading workflow.

Final Result:

  • Students have both granular points (TaskPoint records) and final grade (Participation#grade_value)

Phase 12: Late Adjustments & Recomputation

Scenario

A student's coursework grade changes after the initial bulk computation.

System Response:

TriggerAction
Grade ChangeThe system automatically triggers StudentPerformance::Service.compute_and_upsert_record_for(user).
UpdateThe factual data (points_total, achievements_met) in the student's StudentPerformance::Record is updated.
PreserveAny manual override_status on the record remains untouched.
EffectThe next time the student's eligibility is checked (e.g., on the overview screen or during an exam registration attempt), the Evaluator will use the new factual data, providing an up-to-date status.

Phase 12: Late Adjustments & Recomputation

Scenario

A student's coursework grade changes after certifications have been created.

System Response:

TriggerAction
Grade ChangeThe system automatically triggers StudentPerformance::Service.compute_and_upsert_record_for(user).
UpdateThe factual data (points_total, achievements_met) in the student's StudentPerformance::Record is updated.
Mark StaleThe associated Certification is marked for review (e.g., needs_review: true flag).
NotifySystem alerts staff that certifications need re-review.
Re-CertifyStaff must review and re-certify before any new campaigns can open.

Certification Stability

Once a certification is created, it remains valid until explicitly updated by staff, even if the underlying Record changes. This ensures consistency during active registration campaigns.


Phase 13: Reporting & Administration

Goal

Ongoing monitoring and data integrity

Ongoing Activities:

ActivitySource
Participation ReportsAssessment::Participation data
Eligibility ExportStudentPerformance::Record
Registration AuditRegistration::UserRegistration
Roster AdjustmentsRoster::MaintenanceService as needed
Data IntegrityBackground jobs monitoring consistency

Key Invariants Throughout the Workflow

System Constraints

These constraints are maintained across all phases to ensure data integrity.


Phase 13: Reporting & Administration

Goal

Ongoing monitoring and data integrity

Ongoing Activities:

ActivitySource
Participation ReportsAssessment::Participation data
Eligibility ExportStudentPerformance::Certification
Registration AuditRegistration::UserRegistration
Roster AdjustmentsRoster::MaintenanceService as needed
Data IntegrityBackground jobs monitoring consistency

Key Invariants Throughout the Workflow

System Constraints

These constraints are maintained across all phases to ensure data integrity.

InvariantDescription
One Record per (lecture, user)StudentPerformance::Record uniqueness.
One Certification per (lecture, user)StudentPerformance::Certification uniqueness.
One Participation per (assessment, user)Assessment::Participation uniqueness.
One Confirmed Registration per (user, campaign)Registration::UserRegistration constraint.
One TaskPoint per (participation, task)Assessment::TaskPoint uniqueness.
Idempotent Materializationmaterialize_allocation! produces the same results with the same inputs.
Ordered Policy EvaluationShort-circuits on the first failure.
Certification CompletenessCampaigns cannot open or finalize without complete, non-pending certifications.
Certification StabilityExisting certifications remain valid until explicitly updated by staff.
Phase-Aware PoliciesOnly policies matching the current phase are evaluated.
Exam Assessment TimingCreated only after exam registration closes.

Chronological Summary

High-Level Flow

A bird's-eye view of the complete workflow from setup to final grades.

PhaseSummary
SetupCreate domain models → Configure registrables & rosters
RegistrationOpen campaign → Students register → (Optional: Run solver) → Materialize to rosters
CourseworkSeed participations → Define tasks → Students submit → Tutors grade → Publish results
PerformanceRecord achievements → Compute performance records
CertificationGenerate proposals → Teachers review → Create certifications → Verify completeness
Exam RegistrationPre-flight checks → Open campaign → Students register → Close campaign
FinalizationValidate certifications → Materialize to exam roster → Complete campaign
Exam GradingSeed exam participations → Grade tasks → Apply grade scheme → Publish grades
OngoingMaintain rosters → Update grades → Recompute records → Re-certify as needed

Sequence Diagram

sequenceDiagram
    participant Student
    participant Campaign
    participant Solver
    participant Materializer
    participant Rosterable
    participant Assessment
    participant PerfService as StudentPerformance::Service
    participant PerfRecord as StudentPerformance::Record
    participant Teacher
    participant Evaluator as StudentPerformance::Evaluator
    participant Certification as StudentPerformance::Certification
    participant ExamCampaign
    participant Policy as Registration::Policy

    Student->>Campaign: Visit campaign page
    Campaign->>Policy: Evaluate eligibility (registration phase)
    alt Not eligible
        Campaign-->>Student: Show error with reason
    else Eligible
        Campaign-->>Student: Show registration interface
        Student->>Campaign: Submit registration (FCFS or preference)
    end
    Note over Campaign: If preference mode...
    Campaign->>Solver: Run assignment at deadline
    Solver-->>Campaign: Set confirmed/rejected

    Campaign->>Materializer: finalize!
    Materializer->>Rosterable: materialize_allocation!(user_ids)
    Note over Rosterable: Tutorial/Talk rosters updated

    Assessment->>Rosterable: Seed participations from roster
    Student->>Assessment: Submit coursework
    Note over Assessment: Tutors grade → TaskPoints created

    Assessment->>PerfService: Grading events trigger updates
    PerfService->>PerfRecord: compute_and_upsert_record_for(user)
    Note over PerfRecord: Factual record updated (points, achievements)

    rect rgb(255, 245, 235)
    note over Teacher,Certification: Teacher Certification Phase
    Teacher->>Evaluator: bulk_proposals(lecture)
    Evaluator->>PerfRecord: Read all records
    Evaluator-->>Teacher: Generate eligibility proposals
    Teacher->>Teacher: Review proposals
    Teacher->>Certification: Create certifications (passed/failed)
    Note over Certification: All students certified
    end

    rect rgb(235, 245, 255)
    note over Student,Policy: Exam Registration Phase
    Teacher->>ExamCampaign: Attempt to open campaign
    ExamCampaign->>Certification: Pre-flight: verify completeness
    Certification-->>ExamCampaign: All certifications complete
    ExamCampaign->>ExamCampaign: Transition to open

    Student->>ExamCampaign: Visit exam registration page
    ExamCampaign->>Policy: Evaluate student_performance policy
    Policy->>Certification: Lookup certification for student
    Certification-->>Policy: Return status (passed/failed)
    alt Passed certification
        Policy-->>ExamCampaign: Pass result
        ExamCampaign-->>Student: Show register button
        Student->>ExamCampaign: Click register
        ExamCampaign-->>Student: Confirm registration
    else Failed/pending certification
        Policy-->>ExamCampaign: Fail result
        ExamCampaign-->>Student: Show error (not eligible)
    end
    end

    rect rgb(245, 255, 245)
    note over Teacher,Rosterable: Finalization Phase
    Teacher->>ExamCampaign: Trigger finalize!
    ExamCampaign->>Certification: Validate completeness again
    Certification-->>ExamCampaign: All complete
    ExamCampaign->>Rosterable: materialize_allocation!(eligible_user_ids)
    Note over Rosterable: Exam roster materialized
    end

    Note over Assessment: After exam...
    Assessment->>Assessment: Grade exam tasks
    Assessment->>Assessment: Apply grade scheme
    Assessment-->>Student: Final grades published