Transition to University 5.0
How a university can connect existing educational, scientific and digital practices without having to replace them all at once.
A transition begins by finding out how tasks are carried out now, who is responsible for results and where existing systems stop sharing useful context.
Each proposed stage adds a working mechanism. A limited pilot tests it before a wider decision is made.
The pilot's observed results determine whether the work can be extended, which assumptions were wrong and what the institution should examine next.
University 5.0 and EduOS Lad are research architectures under development. The institutional scenarios, readiness values and system capabilities below are illustrative rather than verified deployments.
Explore the research
Show contentsHide contents
- 01Where the transition begins
- 02Architecture of the transition
- 03Initial diagnosis
- 04Map the present state
- 05Target architecture
- 06Assemble a target configuration
- 07Stage 1: Events and results
- 08Stage 2: Competence graph
- 09Stage 3: EduOS and agents
- 10Stage 4: Digital twin
- 11Stage 5: Data and rules
- 12Stage 6: Reproductive cycle
- 13Explore the six stages
- 14Pilots and scaling
- 15Choose a starting pilot
- 16Transition dependencies
- 17Requirements for the next stage
- 18People responsible for change
- 19Review checkpoints
- 20Assess each stage
- 21Possible roadmaps
- 22Select a transition route
- 23Complete worked scenario
- 24Architectural principles
- 25Conclusions
- 26About the author's model
- 01Where the transition begins
- 02Architecture of the transition
- 03Initial diagnosis
- 04Map the present state
- 05Target architecture
- 06Assemble a target configuration
- 07Stage 1: Events and results
- 08Stage 2: Competence graph
- 09Stage 3: EduOS and agents
- 10Stage 4: Digital twin
- 11Stage 5: Data and rules
- 12Stage 6: Reproductive cycle
- 13Explore the six stages
- 14Pilots and scaling
- 15Choose a starting pilot
- 16Transition dependencies
- 17Requirements for the next stage
- 18People responsible for change
- 19Review checkpoints
- 20Assess each stage
- 21Possible roadmaps
- 22Select a transition route
- 23Complete worked scenario
- 24Architectural principles
- 25Conclusions
- 26About the author's model
A transition begins with a grounded view of the university
A useful diagnosis describes actual tasks, processes, roles, data, digital systems, resources and the relationships between them. It distinguishes practices that already work from isolated local arrangements and relationships that have yet to be designed.
Three structures serve different purposes: seven architectural levels describe the intended model, six institutional stages order the work, and an eighteen-action scenario illustrates one possible implementation sequence.
- Learning tasks
- Outcomes and assessment
- Competence frameworks
- Timetables
- Projects
- Research
- Data
- Digital systems
- Spaces and equipment
- Management decisions
- Roles
- Rules
Explore the transition in the University 5.0 model
The interactive model is a separate research illustration. Its interface is currently in Russian.
Open the model (Russian)Seven levels describe the intended institutional model
Architectural levels describe what needs to be connected. The six implementation stages and pilot evidence determine when those connections may be adopted.
- Starting point
- An institution with existing systems and unclear connections between them
- Working mechanism
- Describe tasks, roles, data and existing systems
- Responsible participants
- Transition sponsor and participating programme leads
- Limited pilot
- A limited part of one programme or department
- Expected result
- Map of functioning processes, relationships and gaps
- Review criterion
- Participants can review and correct the same picture of the present state
- Following level
- T.02 · Event-driven architecture
Describe how the institution actually works
The proposed assessment distinguishes working institutional processes, isolated mechanisms and missing links. Its descriptions must be checked against records and the experience of the people doing the work. The interactive map below begins without any claimed knowledge of a particular university.
Assess the current state of each area
Choose a status only when you have grounds for it. All ten areas begin as not assessed. The suggested starting points are typical examples, not claims about your institution.
0 of 10 areas assessed locally. Nothing has been saved or submitted.
The target model links activities through shared, traceable objects
Objects in the proposed model
- Event
- Task
- Action
- Result
- Evidence
- Competence
- Pathway
- Role
- Resource
- Rule
- Decision
- Project
- Research question
One possible chain of results
Event → task → action → result → evidence → competence → pathway → next task
Other relationships
- A task uses a resource.
- A role performs an action.
- A rule constrains a decision.
- A project produces practical evidence.
- Reviewed evidence may inform another investigation.
Choose the activity from which to build the first connections
An educational programme, laboratory, project team or resource process gives the proposed architecture a different starting point. Choose one to inspect the required relationships and a limited pilot.
- Objects
- Event, task, result, evidence, competence and pathway
- Relationships
- Event → task → result → evidence → next step
- Data
- Task status, outcomes and evidence
- People
- Programme lead, lecturer, tutor, coordinator
- Rules
- Assessment, access and reassessment rules
- Possible pilot
- One interdisciplinary module
- Next connection
- Competence graph and individual pathway
Establish a common account of actions and results
Starting situation
Separate descriptions of tasks and their results
Mechanisms to put in place
- Classification of events
- Shared task template
- Roles
- Expected outcomes
- Review criteria
- Change history
Limited pilot
One interdisciplinary learning or project module
Responsible roles
Programme lead, coordinator and lecturer
Expected result
Tasks and results can be traced from an event to completion
Dependency
Agreement to describe tasks in a common format
Criterion for moving on
Participants use the same task template and reviewable change history
Connect participant work to development
Starting situation
Separate competence frameworks in individual programmes
Mechanisms to put in place
- Evidence
- Competencies
- Contexts
- Reviewing roles
- Next tasks
- Individual pathways
Limited pilot
One programme or project team
Responsible roles
Programme lead, tutor and lecturer
Expected result
A reviewed result informs the participant's competence graph and next task
Dependency
A functioning task and result template
Criterion for moving on
The pathway changes in response to actual reviewed evidence
Coordinate tasks and specialist support
Starting situation
Support offered separately by different services
Mechanisms to put in place
- Task context
- Navigation
- Tutor support
- Analytical support
- Critical review
- Coordination
- Access governance
Limited pilot
One full learning-project cycle
Responsible roles
Coordinator, tutor, analyst and lecturer
Expected result
Participants receive current context and support appropriate to their role
Dependency
A functioning competence graph and task template
Criterion for moving on
Support is bound to a specific task and the participant's role
Connect states, data and observations
Starting situation
Disconnected reports and local process records
Mechanisms to put in place
- Object model
- States
- Events
- Sources
- Versions
- Analytical observations
- Views by role
Limited pilot
One programme, project or laboratory
Responsible roles
Digital systems team, analyst and coordinator
Expected result
Decisions can be traced back to source data and process states
Dependency
A coordinated EduOS process and identified sources
Criterion for moving on
Observations have a traceable source and version
Make responsibility and authority explicit
Starting situation
Different institutional procedures and isolated rules
Mechanisms to put in place
- Data provenance
- Rules
- Authority
- Approval routes
- Options
- Human decisions
- Impact review
Limited pilot
One resource or project process
Responsible roles
Governance representative, coordinator and process lead
Expected result
Each authorised decision has reasons, an accountable person and a reviewable consequence
Dependency
A digital twin and traceable analytical observations
Criterion for moving on
Decisions can be traced from evidence to observed consequences
Link research, education and project practice
Starting situation
Parallel research and learning cycles without reliable handovers
Mechanisms to put in place
- Research question
- Educational transformation
- Project task
- Practical evidence
- New hypothesis
- Programme revision
Limited pilot
One research field and a linked practical project
Responsible roles
Research lead, programme lead and coordinator
Expected result
Practical evidence leads to a new research and educational iteration
Dependency
Traceable data, rules and human decisions
Criterion for moving on
Evidence from project practice supports the next research hypothesis
Examine each implementation stage from five perspectives
Architecture, people, data, technology and governance create different dependencies at each stage. Changing the perspective changes the guidance for the selected stage.
Establish a common account of actions and results
Define a shared event-task-result model and the handover between activities.
- Starting point
- Separate descriptions of tasks and their results
- Mechanisms
- Classification of events
- Shared task template
- Roles
- Expected outcomes
- Review criteria
- Change history
- Minimum pilot
- One interdisciplinary learning or project module
- Responsible roles
- Programme lead, coordinator and lecturer
- Intended result
- Tasks and results can be traced from an event to completion
- Dependencies
- Agreement to describe tasks in a common format
- Review before moving on
- Participants use the same task template and reviewable change history
A pilot creates a small, reviewable part of the intended architecture
Interdisciplinary module
- Scale
- One programme
- Tasks
- Events, tasks, results and evidence
- Roles
- Programme lead, lecturers and coordinator
- Data
- Outcomes and task statuses
- Expected result
- Common task template and reviewable history
- Review period
- One semester
- Possible extension
- Related programmes
Project team
- Scale
- One project task
- Tasks
- Roles, actions, result and external obligations
- Roles
- Project coordinator, participants and expert
- Data
- Task status and external deadlines
- Expected result
- Traceable project work
- Review period
- One project cycle
- Possible extension
- Bring the project into a learning programme
Research laboratory
- Scale
- One field
- Tasks
- Research question → experiment → result
- Roles
- Research lead and analyst
- Data
- Experimental evidence and observations
- Expected result
- Scientific result used in an educational module
- Review period
- One experiment cycle
- Possible extension
- Start a research-learning-project cycle
Personal pathway
- Scale
- One programme
- Tasks
- Competence graph and next participant task
- Roles
- Tutor and programme lead
- Data
- Outcomes and evidence
- Expected result
- Pathway revised in response to actual results
- Review period
- One semester
- Possible extension
- Neighbouring programmes
Resource process
- Scale
- One laboratory or room
- Tasks
- Requests, priorities, decision and outcome
- Roles
- Resource owner, coordinator and governance role
- Data
- Resource records from the digital twin
- Expected result
- Traceable resource decision
- Review period
- One allocation cycle
- Possible extension
- Related resources
Event-driven learning intensive
- Scale
- One event
- Tasks
- Event, task, action, result and evidence
- Roles
- Event lead, lecturers and coordinator
- Data
- Outputs from the intensive
- Expected result
- Working link between event and reviewed evidence
- Review period
- Duration of the intensive
- Possible extension
- Consider a regular event-based format
Choose a priority and examine a suitable pilot
The proposal depends on your selected aim. Verify its starting assumptions and agree the pilot with the people who would participate.
- Candidate pilot
- Project module in one programme
- Required starting grounds
- Tasks and results can be described
- Minimum team
- Programme lead, lecturers and tutor
- Evidence to use
- Results and evidence
- Expected result
- Competence graph for one programme
- Following possible step
- Consider extending to related programmes
Each new mechanism depends on results from earlier work
- Common task modelCompetence evidence
- Competence evidenceIndividual pathways
- Individual pathwaysEduOS coordination
- EduOS coordinationDigital-twin states
- Digital-twin statesAnalytics
- AnalyticsAccountable decisions
- Accountable decisionsReproductive research cycle
Dependencies that matter across every stage
- Roles
- Data
- Rules
- Resources
- Change management
- Technical integration
What needs to be in place for the next stage
These are proposed prerequisites and review points, not automatically established readiness statuses for any particular university.
- Starting basis to verify
- Willingness to describe tasks
- Required inputs
- Event types, task template and responsible roles
- Useful additions
- Change history
- Open questions
- Scope of the task template
- Minimum pilot
- One module
- Responsible role
- Programme lead
- Review checkpoint
- First complete cycle using the shared template
- Illustrative readiness condition
- Potentially ready to extend after verification
Change needs people who can decide and people who carry out the work
Transition sponsor
- Area of work
- Institutional coordination
- Responsibility
- Maintain the agreed sequence and review dependencies
- Decision within delegated authority
- Approve movement between stages within delegated authority
Programme lead
- Area of work
- Education
- Responsibility
- Implement the task template and competence graph
- Decision within delegated authority
- Assess programme readiness for the next stage
Research lead
- Area of work
- Research
- Responsibility
- Connect research findings to learning and projects
- Decision within delegated authority
- Authorise relevant research-to-module transitions
Project coordinator
- Area of work
- Practical projects
- Responsibility
- Link project work and education
- Decision within delegated authority
- Propose and coordinate project inclusion in a programme
Digital systems team
- Area of work
- Technical integration
- Responsibility
- Maintain and connect existing systems, EduOS and the proposed twin
- Decision within delegated authority
- Assess integration readiness and approved technical changes
Data owner
- Area of work
- Evidence and provenance
- Responsibility
- Confirm and correct source records
- Decision within delegated authority
- Specify valid uses and scope of data within authority
Governance role
- Area of work
- Rules and authority
- Responsibility
- Review permitted changes to rules and roles
- Decision within delegated authority
- Approve changes to institutional decision rules where authorised
Readiness must be supported by an observable result
Stage 1
- Review point
- First full cycle using the common task template
- Required evidence
- Task and result log
Stage 2
- Review point
- Pathway responds to an actual reviewed result
- Required evidence
- Updated competence graph and review
Stage 3
- Review point
- Participants receive relevant context in their task
- Required evidence
- Support and task context record
Stage 4
- Review point
- One observation is traceable to its source
- Required evidence
- Source owner and version
Stage 5
- Review point
- A decision has traceable grounds and an accountable person
- Required evidence
- Approval route and reviewed consequences
Stage 6
- Review point
- Project evidence produces a further research hypothesis
- Required evidence
- Documented change in research question
Assess each stage without guessing its readiness
The six assessments start as unassessed. Select a state based on verifiable evidence, rather than assuming the university is already ready for the next step.
0 of 6 stages assessed. This local exercise makes no institutional decision and saves nothing.
- Stage 1. Establish a common account of actions and results
Evidence to seek: Task and result log
- Stage 2. Connect participant work to development
Evidence to seek: Updated competence graph and review
- Stage 3. Coordinate tasks and specialist support
Evidence to seek: Support and task context record
- Stage 4. Connect states, data and observations
Evidence to seek: Source owner and version
- Stage 5. Make responsibility and authority explicit
Evidence to seek: Approval route and reviewed consequences
- Stage 6. Link research, education and project practice
Evidence to seek: Documented change in research question
The right starting route depends on existing work
Route A: From an educational programme
- Tasks
- Results
- Competencies
- Individual pathways
- EduOS
- Analytics
Route B: From a project
- Project task
- Roles
- Results
- Practical evidence
- Digital twin
- Reproductive research cycle
Route C: From a research laboratory
- Research question
- Educational module
- Project
- New evidence
- New hypothesis
Route D: From a management process
- Data
- Rules
- Scenarios
- Human decision
- Consequences
- Reviewed architectural revision
Examine a transition route for the kind of work you already have
Route A: From an educational programme
- Tasks
- Results
- Competencies
- Individual pathways
- EduOS
- Analytics
This is a possible sequence, subject to actual dependencies, responsible roles and evidence.
Eighteen actions illustrate an institutional transition
Follow a single illustrative university from mapping its existing work to evaluating whether a wider rollout is justified.
Initial situation
A university has multiple digital and organisational systems. Gaps remain between tasks, roles, data and systems.
The transition needs to preserve continuity
- Each stage is intended to deliver a functioning, reviewable mechanism.
- The mechanism is examined through a limited pilot.
- Expansion begins only after relevant results have been verified.
- Shared objects connect changes: event, task, result and competence.
- Every stage has an accountable owner, participants and review checkpoint.
- Existing teaching, research and management processes continue during the transition.
- Data retains its provenance, owner and scope of applicability.
- Rules are connected to authority and approval procedures.
- Analytical observations can be traced to sources.
- Decisions have reasons, responsible people and consequences that can be examined.
What would make the transition credible
- University 5.0 is approached through a sequence of mechanisms that must work in practice.
- A common description of tasks and outcomes gives participants a starting point.
- A competence graph links reviewed evidence with possible next tasks.
- EduOS would coordinate tasks, roles and specialist support.
- A digital twin would connect states, source data and analytical observations.
- Data, rules and authorised human decisions provide the proposed governance pathway.
- Research, education and projects can generate a repeatable cycle of new questions.
- Every stage needs a limited pilot and evidence before wider adoption.
Every proposed transition depends on a working pilot, a responsible person and evidence that can be reviewed. Scaling is a separate decision, informed by the actual outcomes.
Institutional architecture of University 5.0
The three articles describe how research creates new questions, how decisions retain human responsibility, and how an institution might connect these activities through controlled, reviewed stages.