Scheduling University 5.0: Orchestrating People, Tasks and Resources
Time follows the sequence of meaningful tasks, participant availability, shared resources and review checkpoints.
EduOS Lad is a proposed architecture for comparing schedules, identifying incompatible requirements and preparing authorised decisions. The examples are illustrative, not live bookings.
Task
- Purpose
- Objectives, criteria and expected result
- Participants
- Students, lecturer and coordinator
- Perspective
- task
- Visible stages
- 8 of 8
Work is scheduled around dependencies, not only clock times
The expected result determines required actions. Each action needs inputs, roles, resources, agreed timing and review criteria.
Collect data
- Required input
- Source access
- Responsible role
- Analyst
- Produced result
- Source data
- Critical-path candidate
- Marked as dependent on the main scenario
Without stage durations, dependency estimates and schedule slack, the actual critical path cannot be calculated. Marked stages are illustrative candidates, not a computed critical path.
Seven architectural layers of scheduling
- Layer
- S.01
- Purpose
- Tasks
- Output
- Time and resource demand
Participants have different and sometimes incompatible availability
An available window for one participant does not imply a session can be confirmed for everyone.
- 01
Analyst
Monday morning; Tuesday all day; Thursday after 14:00
- 02
Engineer
Monday after 13:00; Wednesday; Friday morning
- 03
Economist
Tuesday after 12:00; Thursday; Friday
- 04
Lecturer
Monday; Wednesday after 15:00; Friday
- 05
Expert
Thursday 15:00–16:00
- 06
Coordinator
Daily 10:00–16:00
- Missing availability
- No confirmed slot for everyone
- Feasible alternative
- Monday morning with analyst, lecturer and coordinator, followed by a separate engineer/economist review
- Decision role
- Coordinator and lecturer
Spaces, instruments and experts are part of the task
- 01
Classroom
Use: Teaching and meetings. Constraint: Module timetable. Alternative: Project room
- 02
Project room
Use: Team collaboration. Constraint: Other project occupies Wednesday. Alternative: Classroom
- 03
Laboratory
Use: Physical experiments. Constraint: Thursday maintenance. Alternative: Digital model
- 04
Equipment
Use: Measurement and calibration. Constraint: Engineer required. Alternative: Digital simulation
- 05
Digital model
Use: Scenario analysis. Constraint: Compute allocation. Alternative: Manual calculation
- 06
Dataset
Use: Analysis. Constraint: Wednesday version updates. Alternative: Archived data
- 07
Expert consultation
Use: Assessment. Constraint: One hour Thursday. Alternative: Written review
- 08
Compute capacity
Use: Modelling. Constraint: Workday quota. Alternative: Queued calculations
Allocate one laboratory between three competing processes
- Suggested order
- Research → Project → Teaching
- Grounds
- Specialist apparatus needs an uninterrupted run
- Work moved
- Teaching uses a digital model
- Approval
- Lab coordinator
Every displayed allocation remains a proposal until the accountable people approve it.
Seven dependency types
- 01
Subject matter
Cost appraisal needs a technical scenario.
- 02
Information
Analysis needs verified data.
- 03
Resource
Testing requires available equipment.
- 04
Role
Expert review needs expert attendance.
- 05
Decision
A transition needs approval.
- 06
Time
Integration follows individual preparation.
- 07
Project
A pilot follows model review.
Checkpoints enable accountable transitions
- 01
Expected output
The checkpoint must include a responsible role, grounds and the effect on downstream work.
- 02
Review criteria
The checkpoint must include a responsible role, grounds and the effect on downstream work.
- 03
Reviewing role
The checkpoint must include a responsible role, grounds and the effect on downstream work.
- 04
Permitted decisions
The checkpoint must include a responsible role, grounds and the effect on downstream work.
- 05
Dependent tasks
The checkpoint must include a responsible role, grounds and the effect on downstream work.
- 06
Deadline
The checkpoint must include a responsible role, grounds and the effect on downstream work.
- 07
Recorded evidence
The checkpoint must include a responsible role, grounds and the effect on downstream work.
- Work
- Define task and collect data
- Required result
- Available and reviewed source data
A scheduling conflict is a clash of requirements
- 01
Overlapping mandatory meetings
Identify affected participants, constraints and decision authority before choosing a response.
- 02
Two processes require the same resource
Identify affected participants, constraints and decision authority before choosing a response.
- 03
Expert required by two teams
Identify affected participants, constraints and decision authority before choosing a response.
- 04
Task starts without its required input
Identify affected participants, constraints and decision authority before choosing a response.
- 05
Equal deadlines compete for one team
Identify affected participants, constraints and decision authority before choosing a response.
- 06
Incompatible module workload
Identify affected participants, constraints and decision authority before choosing a response.
- 07
New event invalidates the agreed plan
Identify affected participants, constraints and decision authority before choosing a response.
Two teams, one hour of expert availability
Team A requires approximately 40 minutes, Team B 30 minutes. Both full reviews do not fit the expert's one-hour window.
- Response
- Team B receives later written feedback
- Trade-off
- Deeper review for A, delayed B
- Decision belongs to
- Lecturer
New events require new proposals, not unapproved changes
- New readings
- Laboratory closes
- Expert moves appointment
- New partner request
- Participant finishes early
- Proposed order
- Validate data → revise model → redo scenarios → engineer → costs → expert → defence
- Deferred work
- Part of cost work
- Approving role
- Lecturer and coordinator
Individual schedules contribute to a shared result
- 01
Analyst
Individual: Check data and model scenarios. Team: Send assumptions to engineer and economist
- 02
Engineer
Individual: Review feasibility and equipment. Team: Receive analytical scenarios
- 03
Economist
Individual: Evaluate costs and alternatives. Team: Receive technical parameters
- 04
Coordinator
Individual: Trace dependencies and decisions. Team: Integrate work of every role
- Individual work
- Check data and model scenarios
- Shared work
- Send assumptions to engineer and economist
Five connected scheduling scales
- 01
Personal day
This level has its own tasks, resources, commitments and review points.
- 02
Team week
This level has its own tasks, resources, commitments and review points.
- 03
Project cycle
This level has its own tasks, resources, commitments and review points.
- 04
Learning module
This level has its own tasks, resources, commitments and review points.
- 05
University and programme
This level has its own tasks, resources, commitments and review points.
EduOS and specialist agents support orchestration
- 01
Coordinator
Dependencies and sequence
- 02
Resource agent
Capacity, conflicts and alternatives
- 03
Navigator
Current route and changed tasks
- 04
Analyst
Bottlenecks and scenario comparison
- 05
Governance agent
Authority, approvals and decision record
Coordination, resource proposals, navigation, analytical review and governance remain distinct functions. Authority for changes is retained by the roles responsible for the educational and project process.
Fourteen stages of a project week
Follow a campus-energy pilot from an initial task through resources, clashes, approved decisions, participant work and review.
1. Define expected project outcome
Set criteria for a reviewed campus-energy pilot.
Rules and outcomes
- 01
Task-first scheduling
Keep constraints, grounds, ownership and resulting state available for review.
- 02
Explicit input and output dependencies
Keep constraints, grounds, ownership and resulting state available for review.
- 03
Feasible resource windows
Keep constraints, grounds, ownership and resulting state available for review.
- 04
Bounded participant authority
Keep constraints, grounds, ownership and resulting state available for review.
- 05
Review before transition
Keep constraints, grounds, ownership and resulting state available for review.
- 06
Change history and notified participants
Keep constraints, grounds, ownership and resulting state available for review.
About the research model
Scheduling as orchestration is part of Sergey Shatokhin's University 5.0 and EduOS Lad research at IWXA. It describes a proposed relation between individual tasks, interdisciplinary projects, available resources and authorised decisions.
Explore the separate demonstration ↗