Skip to content

Subject Moderation Interface (SMI)

This page gives an overview of the Subject Moderation Interface (SMI), describing its current status, where and how it's developed and deployed, and who is responsible for maintaining it.


This is a prototype service that is not fully supported. See the FAQ for Subject Moderation Interface alpha for more details.

Service Description

The Subject Moderation Interface (SMI) service provides a web application for moderating undergraduate applications as part of the admissions process.

Service Status

The SMI is currently alpha.


Technical queries and support should be directed to and will be picked up by a member of the team working on the service. To ensure that you receive a response, always direct requests to rather than reaching out to team members directly.

Issues discovered in the service or new feature requests should be opened as GitLab issues here.


The SMI is currently deployed to the following environments:

Main Application URL Django Admin URL Backend API URL
Production Live service
Integration End-to-end testing getting as close to production-like as possible
Staging Manual testing before deployment to production and production-like environments
Development Development playground

Environment details:

Environment Deployment Frequency User Access Purpose
Development An environment to check any development code changes without affecting end-users.
Integration An environment to test various interfaces and the interactions between integrated components or systems.
Test An environment to evaluate if a component or system satisfies functional requirements.
Regression An environment to test that defects have not been introduced or uncovered in unchanged areas of the software, as a result of the changes made.
Production An environment where code changes are tested on live user traffic.

The GCP console pages for managing the infrastructure of each component of the deployment are:

Name Main Application Hosting Database Synchronisation Job Application Hosting
Production GCP Cloud Run GCP Cloud SQL (Postgres) GCP Cloud Scheduler
Integration GCP Cloud Run GCP Cloud SQL (Postgres) GCP Cloud Scheduler
Staging GCP Cloud Run GCP Cloud SQL (Postgres) GCP Cloud Scheduler
Development GCP Cloud Run GCP Cloud SQL (Postgres) GCP Cloud Scheduler

All environments share access to a set of secrets stored in the meta-project Secret Manager.

Source code

The source code for the SMI is spread over the following repositories:

Repository Description
Main Application The source code for the main application Docker image
Synchronisation Job Application The source code for the synchronisation job application Docker image
Infrastructure Deployment The Terraform infrastructure code for deploying the applications to GCP


The synchronisation job application repository is named the "Pool Applicant Document Management" repository but the name is misleading as the application manages synchronisation with CamSIS, Google Drive and Google Sheets, and not just for applicant pooling purposes.

Technologies used

The following gives an overview of the technologies the SMI is built on.

Category Language Framework(s)
Web Application Backend Python Django
Web Application Frontend JavaScript React
Synchronisation Job Application Python Flask
Database PostgreSQL n/a

Operational documentation

The following gives an overview of how the SMI is deployed and maintained.

How and where the SMI is deployed

Database for undergraduate applicant data is a PostgreSQL database hosted by GCP Cloud SQL. The main web application is a Django backend with React frontend, hosted by GCP Cloud Run. The synchronisation job application (which provides an API with end-points for synchronising the SMI database with other services) uses the Flask library, is hosted by GCP Cloud Run and invoked by GCP Cloud Scheduler.

The SMI infrastucture is deployed using Terraform, with releases of the main application and synchronisation job application deployed by the GitLab CD pipelines associated with the infrastructure deployment repository.

Deploying a new release

The files in each of the source code repositories explain how to deploy the SMI.

Deployment schedule

All environments are deployed to at sprint end. However, there are some exceptions:

  • Development is only deployed to at sprint end, to keep it up to date, if there is no one currently using it for feature testing. This manual feature testing deployments are only done when a larger piece of functionality needs further testing, after manual development before or during a review.
  • Staging is deployed to on merge to master.

User access management

Environment User access management
Production Google OAuth2
Integration Google OAuth2
Staging Google OAuth2
Development Google OAuth2

However, while being able to use your University Google account to sign in, permissions are initially granted through invitations to the service and managed in the Django Admin console should adjustments be necessary.

In the production environment, all users are removed at the end of an admissions cycle and invitations and permissions re-issued on the start of a new one.


  • GCP Cloud Monitoring for tracking the health of applications in the environments and sending alert emails when problems are detected.
  • Cloud Logs for tracking individual requests/responses to/from the web application and the synchronisation job application.
  • production,
  • test (staging),
  • development)


The files in each of the source code repositories provide information about debugging both local and deployed instances of the applications.


Applicant data is initially retrieved from CamSIS via a synchronisation job (managed by GCP Cloud Scheduler which periodically calls the synchronisation job API). Additional annotations are later added by manually importing the subject master spreadsheet (SMS) and subject-specific variants (using the Django admin application page (staging) for the appropriate environment).

Periodic synchronisation jobs ensure that each applicant has an associated folder on Google Drive (for storing additional documents). They also ensure that applicant data is consistent between the SMI and several linked Google Sheets spreadsheets: the expression of interest master list (EoIML) and poolside meeting outcome spreadsheets (PMOSs). A manually invoked process on CamSIS uses the SMI web application API to retrieve pooling decisions about applicants, and update the CamSIS database as necessary.

The flow of applicant data to/from the SMI and other services is summarised by the diagram below.

Flow of applicant data to/from the SMI

Further information is available in the Operational Documentation for the Undergraduate Admissions process.

Service Management and tech lead

The service owner for the SMI is Helen Reed.

The service manager for the SMI is TBD.

The tech lead for the SMI is Brent Stewart.

The following engineers have operational experience with the SMI and are able to respond to support requests or incidents: