QUINTUPLE CAMPUS
PILOT
Campus is being built as an AI-native core system for institutional work. Agents handle routine tasks within defined boundaries. People retain authority over decisions that matter.
A DIFFERENT OPERATING MODEL
Institutional ERP systems help schools and colleges manage records, transactions and workflows. Many already automate parts of that work.
Campus is being designed around a different operating model: agents carry out permitted routine work, while people set the boundaries, review exceptions and make consequential decisions.
The aim is not to remove people from institutional work. It is to give them more room to exercise judgment.
THE CAMPUS OPERATING MODEL
Campus is organised around five personas. Each covers an area of institutional work; together, they form the intended scope of the system.
Familiar operational workflows sit within those personas rather than being treated as isolated ERP modules.
INSTITUTIONAL WORK
Supports institutional leadership with operational information, financial oversight and reporting.
Work within this area: finance, payroll oversight, institutional reporting, facilities and service operations, and aggregate analysis.
Supports the student journey from the first application through enrolment, progression and exit.
Work within this area: admissions, student records, onboarding, fee-related student workflows and lifecycle administration.
Supports the preparation, organisation and review of information needed for institutional compliance and reporting.
Work within this area: accreditation evidence, regulatory reporting, compliance records and audit preparation.
LEARNING & FACULTY
Supports learning, assessment and student progression. Its purpose is to help students learn and give teachers information they can use in their work.
Work within this area: learning support, concept assessment, student progression and learning records.
Supports the people and operational processes involved in teaching and running an institution.
Work within this area: attendance, faculty records, workload, leave, examination administration and staff operations.
COORDINATION
+1
Coordinates work across the five personas. Where a workflow crosses functions, the orchestrator is intended to route the work while respecting the authority and governance boundaries that apply.
This is the intended scope of Campus, not a statement that every workflow is available today.
INSTITUTIONAL OPERATIONS
Some workflows cross personas. For example, a student’s fee record and the institution’s financial oversight are related, but they are not the same task.
PROPOSED PERSONA SCOPE
| Institutional work | Student Learning Intelligence | Faculty Operations Intelligence | Institutional Compliance Intelligence | Management Decision Intelligence | Admissions & Student Lifecycle |
|---|---|---|---|---|---|
| Admissions and student records | Not mapped here | Not mapped here | Not mapped here | Not mapped here | Proposed scope |
| Attendance | Not mapped here | Proposed scope | Not mapped here | Not mapped here | Not mapped here |
| Fees and financial workflows | Not mapped here | Not mapped here | Not mapped here | Proposed scope | Proposed scope |
| Examinations, marks and results | Proposed scope | Proposed scope | Not mapped here | Not mapped here | Not mapped here |
| HR and payroll | Not mapped here | Proposed scope | Not mapped here | Proposed scope | Not mapped here |
| Institutional communication | Across personas, according to the workflow | ||||
| Library | Proposed scope | Not mapped here | Not mapped here | Proposed scope | Not mapped here |
| Transport, hostel and cafeteriaStudent lifecycle information where needed | Not mapped here | Not mapped here | Not mapped here | Proposed scope | Not mapped here |
| Analytics and reporting | Not mapped here | Not mapped here | Proposed scope | Proposed scope | Not mapped here |
Proposed scope
Proposed scope
Proposed scope
Proposed scope
Proposed scope
Across personas, according to the workflow
Proposed scope
Proposed scope
Student lifecycle information where needed
Proposed scope
Proposed scope
Not mapped here
A dash means “not mapped here”, not “impossible” or “not supported”.
The precise scope and availability of each workflow will be discussed during an institutional briefing.
THE OPERATING MODEL
Campus is built around IaaGS: our method for governing how intelligent systems operate.
An action does not become autonomous simply because an agent can perform it. Its authority depends on what the action does, who it affects and what could happen if it goes wrong.
01
Information arrives or an institutional workflow needs attention.
02
The action is considered against its permitted scope and risk.
03
The agent completes an allowed action or prepares the work for an authorised person to review and decide.
AGENT ACTS WITHIN
ITS AUTHORITY
HUMAN REVIEW
AND DECISION
04
The action, its basis and any required approval are recorded so the institution can review what happened.
This is the governance model Campus is being designed around. Implementation and availability vary by workflow.
THE CAMPUS GOVERNANCE BENCHMARK
Campus is being designed around five levels of consequence. As the potential impact rises, agent authority narrows and human oversight increases.
The levels and examples below describe the intended governance benchmark. They are not a claim that every workflow or control is already deployed.
A level applies to an action, not an entire persona. Context matters: an action may be escalated if it affects more people, exposes sensitive information or is difficult to reverse.
LEVEL 01
An agent may act autonomously within approved rules.
LEVEL 02
An agent may act autonomously only when the institution has pre-authorised that specific action and its conditions are met. Otherwise, human approval is required.
LEVEL 03
The agent prepares or recommends. An authorised person approves before execution.
LEVEL 04
Designated human approval and independent review are required before execution.
LEVEL 05
No autonomous consequential action. The decision and execution remain with authorised people under the applicable institutional process.
These are consequence levels for individual actions, not a sequence an action moves through.
Select a persona to see examples of actions and their intended controls.
02 MODERATE
Action 1: Prepare an authorised institutional report.
Intended control
Autonomous only if specifically pre-authorised; otherwise human approval.
03 HIGH
Action 2: Change payroll values or release payroll.
Intended control
Human approval; exceptional or larger actions may be escalated.
04 CRITICAL
Action 3: Release a bulk payment or make a material bulk financial change.
Intended control
Designated approval and independent review.
03 HIGH
Action 4: Apply a concession or change a fee obligation.
Intended control
Human approval.
01 LOW
Action 5: Flag an overdue library item.
Intended control
Agent acts within approved rules.
02 MODERATE
Action 6: Make a routine room or service allocation.
Intended control
Autonomous only if specifically pre-authorised; otherwise human approval.
01 LOW
Action 1: Flag a missing application document.
Intended control
Agent acts within approved rules.
02 MODERATE
Action 2: Send a standard reminder to a verified contact.
Intended control
Autonomous only if specifically pre-authorised; otherwise human approval.
03 HIGH
Action 3: Accept or reject an application.
Intended control
Human decision and approval.
03 HIGH
Action 4: Apply a concession or change a fee obligation.
Intended control
Human approval.
01 LOW
Action 1: Flag a missing item in a compliance evidence set.
Intended control
Agent acts within approved rules.
03 HIGH
Action 2: Submit an institutional regulatory report.
Intended control
Prepared for authorised human approval.
01 LOW
Action 1: Flag a learning item for a teacher to review.
Intended control
Agent acts within approved rules.
05 HIGHEST CONSEQUENCE
Action 2: Enter, change, approve or publish official examination marks.
Intended control
No autonomous consequential action.
01 LOW
Action 3: Flag an overdue library item.
Intended control
Agent acts within approved rules.
01 LOW
Action 1: Record routine attendance from an authorised source.
Intended control
Agent acts within approved rules and correction controls.
02 MODERATE
Action 2: Send a standard absence notification to a verified guardian.
Intended control
Autonomous only if specifically pre-authorised; otherwise human approval.
03 HIGH
Action 3: Change an attendance record already used for an eligibility decision.
Intended control
Human approval.
05 HIGHEST CONSEQUENCE
Action 4: Enter, change, approve or publish official examination marks.
Intended control
No autonomous consequential action.
03 HIGH
Action 5: Change payroll values or release payroll.
Intended control
Human approval; exceptional or larger actions may be escalated.
04 CRITICAL OR PROHIBITED
No autonomous release; approval cannot override a prohibition.
05 HIGHEST CONSEQUENCE
Escalate to the appropriate people and safety process.
These safeguards apply across personas; they are not a sixth persona.
Pre-authorisation is not a blanket permission for an agent to act.
The institution defines the specific action, when it may run, the information and people it may affect, and when it must stop and request review. Authorisation must also be reviewable and revocable.
If an action falls outside its authority or the context is unclear, the agent refers it to a person.
An authorised employee’s approval permits an institutional action. It does not replace a person’s consent where consent is legally required.
This is the intended governance benchmark. The examples describe proposed controls, not a claim that every workflow or control is already available.
DATA AND ACCESS
An institution needs information to do its work. It also needs boundaries around who can see, change or share that information.
Campus is being designed so that access and agent authority are governed by the task, the data involved and the role requesting it.
Different audiences may need different views:
INDIVIDUAL RECORD
For an authorised task.
COHORT VIEW
For institutional oversight.
AGGREGATE VIEW
For broader reporting.
The views are examples of possible access needs, not a claim that every view or control is already available.
Those boundaries must be defined for the deployment.
We will discuss the applicable data responsibilities and controls during an institutional briefing.
THE TRANSITION
An existing ERP holds records and supports processes your people depend on. Any move to a new core system must account for that work, the data behind it and the people who use it.
A conversation about Campus starts with understanding your current setup: what works, where routine work depends on manual follow-through, and where the institution needs greater control or visibility.
The scope and approach would be discussed for your institution. We do not assume that every system or workflow can be replaced in one step.
ONE SYSTEM, TWO SCOPES
QUINTUPLE ACADEMY
Quintuple Academy is the programme-focused edition, supporting the learning and programme experience.
Explore AcademyQUINTUPLE CAMPUS
Quintuple Campus is the broader institutional edition being built to support work across the five personas.
They are different scopes of the same system. Which one is relevant depends on what your institution is trying to do.
WHAT WE CAN SHOW
STATUS
Campus is in pilot.
SCOPE
The institutional scope and governance model on this page describe what we are building towards; they should not be read as a claim that every function is complete.
BRIEFING
In a briefing, we will discuss what can be demonstrated for your requirements, what remains in development or design, and what needs further assessment before deployment.
If a capability you need is not ready to show, we should say so.
AN INSTITUTIONAL CONVERSATION
Tell us about your institution, the systems you use today and the workflows you want to improve. We can discuss whether Campus is a fit, what can be demonstrated and what a scoped engagement would involve.
Institutional pricing is available on request.
Request an institutional briefing