ScholarCloud: the learning system and the record, shown

Purpose and the people it serves

A university runs three systems of record for its scholars. AutoScholar advises students and the staff who look after them. Giants' Shoulders holds research. ScholarCloud is the teaching and records system: the learning management system and the student information system on one database, behind one sign-in, with one identity for every person. Marks made in a class reach the permanent record through a deliberate publish step, and the record feeds the class back its cohort.

Five people use it, and each sees the modules their role needs. The lecturer runs classes, writes content, marks and watches who is behind. The student reads, submits, sits tests and tracks the week. The parent or tutor on a student's support team sees the same tracker, read-only. The registrar runs admissions, registration, the record, finance, examinations, the statutory returns, research and staff records. The prospective student uses the hub to find a programme at any connected institution and to apply with one dossier.

Sign-in and modules
Find your programme
Admissions
Learning
Teaching content
The student and the parent
Records
The hub
Where it runs
State on 15 September

Sign-in and the module chooser

One sign-in serves every role. After it, the chooser offers the modules the person's role allows: Find your programme, Admissions, Learning, Teaching content, Records and About. The demonstration instance carries five accounts, one per role, so the same class and the same records can be seen from each side.

The module chooser after sign-in — **The module chooser.** Six tiles for the registrar's account. A student's account shows three.

Find your programme: the register across the network

The register lists every programme the connected institutions publish, built nightly from each institution's own programme tables and served as one static file, so browsing is instant and survives an institution's system being down. The counters at the top are the register's own: three institutions, 113 programmes with a published structure, 2,940 programme codes, 2,943 modules, and the programmes whose admission requirement has been published. The filters on the left cut by listing, institution, fit, qualification and level. A card opens the programme with its modules by year and the door into that institution's application.

The programme register across three institutions with its filters and counters — **The register.** Every programme on the network, the counters, and the filters by listing, institution, fit, qualification and level. The same register opens inside each institution's own system and on the hub, where this was captured.

Admissions: the front door

An application is a member's draft with programme choices, documents by kind and provisional results, submitted against a selection rule for the intake year: a minimum admission point score, subject minimums and a capacity. The rule sorts a submitted application into met or borderline. Borderline applications go to the committee, which decides. A met application receives an offer, firm or conditional. An accepted offer is converted into a student and a programme registration on the record in one step.

The admissions funnel: applications in lanes by state — **Funnel.** Four applications in the demonstration cycle, in the lanes accepted, borderline and draft.

The committee desk: borderline admissions pending — **Committee.** The approvals desk with the borderline admissions awaiting a decision. One has been approved.

Conversion: accepted applications with the convert action — **Conversion.** Two accepted applications, each with the action that creates the student and the registration.

Learning: the class, the marks, the activity, the early warning

The class on one screen

Opening a class shows the semester plan in week order on the left, with readings, a practice unit, quizzes, a lab report and an essay in the weeks they are due. The roster in the centre, each student with the count of items done against those due. And the gradebook summary and announcements on the right. Content, a test or an assignment is added from the same header.

The class view: semester plan, roster, gradebook summary and announcements — **Physical Chemistry 2, second semester 2026.** Nine students, a six-week sequence, six graded items with their release state and the count graded.

Marks, from the item to the final grade

The grader report lists every student against every item. Items sit under weighted categories, tests and coursework, and each cell is banded by performance. The overall mark and letter grade are computed as marks arrive. The panel on the right enters marks for one item across the class and releases the item to students. Written work reaches the marking queue: each submission opens in a grading card with the text, the mark out of the maximum, feedback, and a step to the next unmarked piece.

The grader report with category weights, item marks and the enter-marks panel — **The grader report.** Test 1, the lab report, the quiz, the essay and the second lab report under two weighted categories. The lab report being entered on the right.

To mark: the queue of submissions and the grading card for one — **To mark.** Three submissions waiting. One opened with its text, the mark field out of fifty, feedback and Save and next unmarked.

The class's own activity

Four tabs hold what happens in the class between assessments. Discussion is the class forum, threads started by students and answered by the lecturer. Polls are launched on the class, single-choice or scale, answered once per person, and closed when the reading is done. Attendance is taken per session and read as a heatmap by student and week, with the roll for one session beneath it. Competencies map the class's framework to students and to the activities that evidence them.

Discussion: three threads with post counts and authors — **Discussion.** Three threads: a welcome from the lecturer and two questions from students with replies.

Polls: the surveys in the class's scope, one closed and one open — **Polls.** Two surveys in the class's scope, a closed confidence scale and an open pace check. The panes to the right edit, invite, read respondents and review.

Attendance heatmap by student and week with the roll below — **Attendance.** Eight students over two sessions, the rate per cell, and the week 4 roll with present, late and absent marked.

Competencies: the class framework as a tree — **Competencies.** The class framework, two competencies with their sub-skills. Picking one rates the class against it.

Seeing who is behind, and acting

Insights derives, for each student, progress through the sequence, last activity, work submitted and attendance, and flags the ones at risk. It is the same telemetry an institution's advising system reads. The Support tab lists every student behind their pacing across all classes with two actions on each row: open a support case, or schedule a one-to-one session. A case carries a timeline of notes, interventions and outcomes.

Insights: per-student progress, last activity, submitted work and status — **Insights.** Derived live for the class. The telemetry strip at the top shows what the risk engine sees.

Early warning: students behind, with Open support case and Schedule session on each row — **Early warning.** Students behind in the first-semester class. One already has a case open. Captured 11 September.

The lecturer's home and the students they support

The lecturer's Home: four classes, counts, and the shortcuts — **Home.** Four classes with enrolment counts, eleven students, two assessments open, four items to mark, and shortcuts to compose content, the AI assistant and marking.

Students I support: two learners on the lecturer's support team — **Students I support.** Two learners whose support team names this lecturer as teacher, each opening to their plan.

Teaching content: written where it is taught

Content is authored in the same place it is used. The editor on the left holds one block at a time, text with equations, a figure, a callout or an assessment item, and the preview on the right shows what the student will read. A document can be started from a template, imported, or drafted with a language model of the institution's choosing. Publishing carries a review state from draft through review to published, contributors with their identifiers, and the metadata a catalogue or a registration agency needs.

The content editor with the live student preview beside it — **Compose.** One block being edited on the left, the student's view of the chapter on the right: the equation rendered, a callout, a question with a worked hint. Captured 11 September.

Publish: status and review, identifiers and contributors — **Publish.** The status ladder draft, in review, published. The review notes. The identifier strip for DOI, ISBN, licence and subject scheme. The contributor form with ORCID and role.

The student's day, and the parent's view of it

A student's Home answers what to do next. Do now lists today's items across subjects, or says that nothing is scheduled. Your subjects shows each class with its progress and the next item. Track shows the daily goal, the streak and twelve weeks of activity, derived from real reading and assessment activity. Tasks gathers notifications, recent results, peer reviews to do, the calendar and what is due, with the submit and sit actions on the rows. A class page shows the lesson sequence by week with each item done or upcoming, the student's marks with their release state, announcements, the discussion and the open polls.

The student's Home: Do now, subjects, the tracker, tasks and what is due — **Home.** A Tuesday morning with nothing scheduled in Do now, three subjects on track with the next item on each, the tracker with a streak and a twelve-week grid, three results released, two peer reviews to do, one essay due and two quizzes graded.

The student's class page: lessons by week, marks, announcements, discussion and polls — **The class page.** Two of six lessons done, six marks with one released, the lecturer's announcement, three discussion threads, two open polls with one answered.

A parent, guardian or tutor added to a student's support team signs in with their own account and sees the student under My students, read-only, with the same tracker and plan.

The parent's My students: one child, view only — **My students, as a parent.** One child on the team, marked view only, with the action to add another.

Records: the system of record

Records is the student information system: the students, their programme and course registrations, their results and matric subjects, and the offices that work on them. The demonstration record holds 415 students, 2,219 programme registrations and 5,905 course results imported from institutional reports, so every tab below runs over a real-sized cohort.

The record, the editor, the import

A student record: heading, credit-weighted average by year, credits toward degree, best results and the transcript — **Academic records.** One student opened from the browser of 415: the standing and the credit-weighted average by year, credits toward the degree, best results, and the transcript with its coursework, assessments, registrations and matric tabs.

The records editor over the students table — **Records editor.** The five tables of the record, students open, with browse, create, edit and delete on each.

Data import: an institutional report parsed in the browser — **Data import.** An institutional programme report dropped or pasted, read in the browser, parsed and committed as one batch. The institution API, publish-from-offering and import history beside it.

Academic standing over a cohort

The ERS check is the academic-standing and exclusion workbench that AutoScholar runs at two institutions, here run over ScholarCloud's own record. A programme cohort loads, the rules are read and edited as a decision flow, and the full check writes a decision per student that a reviewer confirms or overrides.

ERS check: a programme cohort of 314 students with the decision criteria, rule editor and flow editor — **ERS check.** A civil engineering cohort of 314 students loaded, none yet reviewed, one student selected. The criteria, the rule editor, the flow editor and the ruleset version above.

Curriculum, finance, examinations

Catalogue changes are made as change sets: proposed, submitted, approved by a second person, then released for an intake year and applied. Student finance is an append-only ledger per account: charges, payments, an instalment plan and financial aid with its disbursements. Examinations hold sessions in venues, the seat allocation for a cohort, and mark capture in double-entry runs with a tolerance.

Curriculum: change sets and releases — **Curriculum.** One change set, a credit change on a module for the 2027 intake, approved and applied. The 2027 catalogue release published. The rule preview beneath.

Finance: student accounts and one statement — **Finance.** Four accounts. One opened with its balance, the ageing strip and the statement of a tuition charge and the payment that cleared it.

Examinations: one session with its venue and seating — **Examinations.** The main session for a first-year chemistry module: date, hours, venue and the seats allocated.

Statutory returns, research, staff

HEMIS readiness is continuous. Every check in the year's dictionary pack runs over the live record and the strip says whether the return would pass. A census freezes the record at a date with a content hash, and a submission is cut from a census. Research holds outputs with their authorships and accredited-list checks, grant calls with applications and awards, and postgraduate candidatures with supervision and milestones, from which the research units are derived. Staff shows the profile and appointments the staff system keeps.

HEMIS: compliance strip, the dictionary pack, census snapshots and submissions — **HEMIS.** Compliance red on one fatal check, seven results against a course the catalogue does not carry. The 2026 dictionary pack armed. The mid-year census frozen with its hash. No submission cut yet.

Research: outputs, grant applications and candidatures — **Research.** One output in draft with its identifier, two applications on one call with one awarded, one masters candidature active.

Staff. The staff profile with department and appointment type. Appointments list beneath it as they load.

The hub: one account across institutions

The student hub at scholarcloud.live is the front door for a student who moves between institutions. Without an account, anyone browses the register. With an account, a student links each institution by signing in through that institution's own system once, and the hub then reads registrations, results and applications live with the student's own session there. The institutions keep their data. The student gets one view. The hub stores the account, the links and the dossier, and almost nothing else.

One programme opened: modules by year and the shortlist action — **A programme page.** Thirty modules by year with codes and credits, the count already covered by the student's record, and the shortlist action.

Signed in: the fit strip judged against the dossier, and the shortlist — **Signed in.** Your fit judged from the dossier's matric subjects where a requirement is published, the shortlist held on the dossier, and the compare panel.

Me: the account, the linked institution, the dossier and the CV — **Me.** The account, an institution linked through its own sign-in, the dossier with subjects and the admission point score, documents, and the CV.

My record: registrations and results read live from the linked institution — **My record.** Thirteen rows read live from the linked institution with the student's own session, one timeline by year, nothing copied.

Applying anywhere with one dossier

Every application asks for the same things: an identity number, the matric subjects with marks, the identity document and the results certificate. The hub holds these once as the dossier and carries them into each application. A programme page ends in the door: apply at the institution on its own application page, with the session the student holds there carried across and the programme already the first choice. Or enquire first. Where an institution's system takes applications only through a page the hub hosts, the door boots that institution's application on its own system. Documents travel as files into the institution's own store, and matric marks arrive as the application's provisional results.

How do I get in? Apply at the institution, or send an enquiry — **The door.** Apply at the institution, or enquire. The student's enquiries about this programme listed beneath. Captured 11 September.

The institution's application page opened with the found programme as choice one — **At the institution.** The application opens with the programme from the hub as choice one, without a second sign-in. Captured 11 September.

The dossier's documents: an identity document listed, and the upload form — **The dossier's documents.** Uploaded once, by kind. Opened or removed from the same list. Captured 11 September.

The institution's application with the identity document already attached — **Arrived with the application.** The identity document attached as the draft opens, one of the two required kinds. Captured 11 September.

Applications across the network, read from each linked institution — **Applications.** Read live from each linked institution: a draft with its first choice, the cycle and the results state. The shortlist as the feed for a new one. Captured 11 September.

The hub-hosted door booting an institution's application on its own system — **A hosted door.** The application portal of a second institution, booted by the hub on that institution's own system and wire.

Messages and the CV

A message to an institution's registration office is a thread created in that institution's own system, as the student, with the office member the institution named as the other participant. The office answers there and the hub reads the thread back. The CV is composed from the record read across institutions, one qualification per programme registration with the institution's average mark, extended by the student with achievements and shared by a link that expires and can be revoked.

Messages: the registration offices, the composer and a thread — **Messages.** A linked institution's registration office picked, a message sent, the thread listed from the institution's own system.

The conversation with a registration office — **The thread opened.** The office named among the participants. The office answers in the same thread. Captured 11 September.

My CV composed from the record, with a share link made — **My CV.** Composed from the record: one qualification per programme registration with the average mark. A share link made beneath it.

A shared CV opened by its link — **A shared CV.** Opened by a reader through the link. Captured 11 September.

Where it runs, and what a deployment needs

The same platform as AutoScholar. ScholarCloud is built on the services, database and interface library that run AutoScholar at two universities, so an institution that has one already has the foundation for the other. The ERS check above is that shared code.
Hosted in South Africa, on infrastructure the institution chooses. Teaching and records run independently of the campus network.
Data stays with the institution. The hub reads a student's record through the student's own institutional session. Nothing is copied out.
What a deployment needs. A server, the institution's programme and module structure imported once, and the sign-in bridge to the institution's student system. Deployments run from one served codebase, so a fix reaches every institution at once.

State on 15 September 2026

Every screen above is the demonstration instance, populated through the system's own verbs and never seeded: one institution's record of 415 students imported from programme reports, four classes with nine to ten students each, two semesters of activity in one class, and a network register built from three institutions' programme tables. Forty-five screens were captured headless as five accounts. Eleven of the hub figures marked 11 September are from the previous capture of surfaces the automated walk does not reach and are unchanged since. Figures are in img/, built by one crop map from the full-page captures, so any one can be retaken.

What is empty on the instance is empty because no one has made those rows yet: class groups, the HEMIS submissions board, the compliance detail behind its sub-tabs, and the second institution's door, which opens on its sign-in. The admissions funnel and the finance accounts label rows by identifier rather than by name. Marks in the class are demonstration marks. The record's results are real-shaped imports.