Education operations schedule

#01Purpose and status of this schedule

This Education Operations Schedule (the "schedule") sets out how ACADEMYSHIP PTY LTD (ACN 698 283 448, ABN 89 698 283 448) ("Academyship", "we", "us") and an Institution share responsibility for Academyship's education and campus-operations modules, and the practical limits of those modules. It is written for the people who choose, configure and govern those modules: Institution administrators and academic, compliance, safeguarding, procurement and operations staff.

This is an institution-facing contract schedule. It applies to an Institution only as described in section 2. It is not a privacy notice, a student or staff guide, or a payer explanation. It does not make a student, guardian, staff member, visitor, external reviewer or other individual a party to the Institution's agreement with Academyship, and it does not limit any right those individuals have under law. Individuals should read their Institution's own notices, Academyship's Privacy Policy and, for students, the Student Privacy Guide.

Each chapter describes what a module can do when an Institution enables it. Modules are available by plan and configuration. Not every module or function is available to every Institution, and this schedule does not state that any module is enabled for a particular Institution. Chapters 7 to 16 each use the same six headings: what the module does; Institution responsibilities; Academyship responsibilities; data and visibility; limits; and corrections and disputes.

#02When this schedule applies

This schedule forms part of an Institution's agreement with Academyship only if:

1. a signed or accepted Order Form identifies this schedule by name and version; or
2. a representative authorised to bind the Institution enables a module covered by this schedule through Academyship's institutional acceptance process, and that process identifies this schedule by name and version.

It then applies only to the modules the Institution has enabled ("Enabled Modules"), and only to the module-specific subject matter of each Enabled Module. A chapter about a module the Institution has not enabled does not apply to that Institution. A User's ordinary use of a module does not make that User a party to this schedule and does not, on its own, enable a module for the Institution.

Some provisions apply only to particular kinds of Institution or particular circumstances:

• Chapter 9 (VET, RPL and compliance) applies only where the Institution enables vocational education and training, recognition of prior learning, training-product, USI or compliance functions. It does not impose vocational rules on a school, university or other Institution that does not use those functions.
• Provisions about children apply only where the Institution's Users or the people it records include people under 18.
• Provisions about guardians apply only where the Institution enables guardian access, guardian linking or guardian notifications. Adult students are not treated as children, or as subject to school-style supervision, merely because they use a student account (Terms section 5).

Disabling a module stops further use of its functions but may not delete the records already created in it. Records created while a module was enabled remain Customer Data, and this schedule continues to apply to them until they are deleted or returned under the Terms and the DPA.

#03Order of precedence

Where this schedule applies and documents conflict, the following order applies, highest first:

1. a signed Order Form or government schedule, to the extent it expressly overrides an identified provision;
2. the Data Processing Addendum, for matters concerning Customer Data;
3. this schedule, for the module-specific subject matter of an Enabled Module;
4. the Terms of Service; and
5. the Acceptable Use Policy.

This schedule supplements the Terms for Enabled Modules. It does not change the Terms' provisions on Fees, warranties, liability, indemnities, suspension or termination unless it expressly says so, and it does not expand the purposes for which Academyship may process Customer Data under the DPA.

The version of this schedule that applies to an Institution is the version identified in its Order Form or activation record. A later version applies only as described in section 21. Informational documents mentioned in this schedule, including the Privacy Policy, Cookie Policy, Child Safety Statement, Responsible AI Statement, student guides and the data retention and complaints information, explain practices and give notices. This schedule does not incorporate them as contractual terms.

#04Definitions

Capitalised terms not defined here, including Customer, Institution, Customer Data, Student Data, User, Tenant, Order Form, Fees, Sensitive Information, Regulated Identifiers, AI Features, Integration and Subprocessor, have the meanings given in the Terms and the DPA. In this schedule:

• Enabled Module — a module covered by this schedule that the Institution has enabled, as described in section 2.
• Institutional Records — records the Institution creates or keeps in an Enabled Module for its educational, administrative, welfare, safety, financial or regulatory purposes. Institutional Records are Customer Data.
• Institution Charges — amounts an Institution charges its students, payers or others, such as tuition, instalments, canteen orders, meal plans, library fines or booking fees. Institution Charges are not Fees. A person who pays an Institution Charge does not thereby buy Academyship's services.
• Generated Credential — a certificate, statement, transcript, letter, card or similar document that the platform generates from an Institution template and Institution data.
• Public Verification — the optional function that lets a person holding a valid verification link or code check limited details of a Generated Credential without signing in, as described in section 10.
• Guardian — a parent, carer or other person whom the Institution links to a student's record or portal account. A Linked Guardian is a Guardian the Institution has linked in the platform.
• Adult Learner — a student aged 18 or over, or a student the law otherwise treats as able to act for themselves in the relevant matter.
• Rule-based Process — an automated process that applies rules, thresholds or calculations, whether configured by the Institution or built into a module, such as a grade calculation, a behaviour-points threshold, a fine calculation, a hold expiry, a waitlist offer or an access check. A Rule-based Process may or may not use AI.
• External Recipient — a person or service outside the Institution's workspace who receives information from an Enabled Module, such as the holder of a verification link, an external reviewer, a calendar provider or the recipient of an email or SMS.
• Payments and Wallets Schedule — Academyship's payments and wallets schedule, which governs payment features where it applies to the Institution.

#05Shared responsibility

The Institution operates the educational and campus service. Academyship provides the software that supports it. Each chapter adds module-specific detail to the general allocation below.

What the Institution is responsible for in every Enabled Module

• deciding whether to enable each module, and which functions, fields, roles, notifications and integrations to use;
• having the lawful authority to collect, use and disclose the information it puts into a module, and giving the collection notices and obtaining the consents the law requires of it (Terms section 12);
• the accuracy of the information it and its Users enter or import, and checking outputs before relying on them;
• making, and keeping a person accountable for, every educational, assessment, credential, disciplinary, welfare, safety, financial and access decision, including decisions supported by a Rule-based Process or an AI Feature;
• setting and publishing its own rules, such as academic, assessment, behaviour, library, canteen, booking and visitor rules, and applying them fairly;
• assigning roles on a least-privilege basis, reviewing them, and removing access that is no longer needed;
• training its staff to use the modules appropriately, including free-text fields;
• keeping the records the law requires it to keep, including by exporting them before they are deleted (section 18);
• handling requests, complaints, reviews and appeals about its own decisions; and
• complying with the education, VET, privacy, records, child-safety, food-safety, consumer and other laws that apply to it.

What Academyship is responsible for in every Enabled Module

• providing and operating each Enabled Module with due care and skill (Terms section 25);
• processing Customer Data only to provide the Services, on the Institution's documented instructions and as the DPA permits;
• maintaining the security measures in Annex II of the DPA and applying the roles and permissions the Institution configures;
• not changing Institutional Records except on the Institution's instructions, in authorised support, or to recover from a platform incident;
• providing export functions for Institutional Records (section 18);
• investigating reported platform faults through the support process, working to correct confirmed faults in its software, and telling the Institution when a confirmed fault may have affected the accuracy, visibility or delivery of its Institutional Records, so the Institution can review them;
• notifying the Institution of a Personal Data Breach in accordance with DPA section 17; and
• complying with the laws that apply to Academyship, including its own privacy obligations and its handling of reports made to it.

The Institution is responsible for the acts and omissions of its Users (Terms section 6). Academyship is responsible for its own software, personnel and conduct. Neither allocation removes a duty that the law places directly on either party.

#06No blanket compliance warranty

The modules support an Institution's processes. They do not perform the Institution's legal role for it. In particular:

• Academyship does not warrant that using a module, or accepting its default settings, will make the Institution compliant with any education, VET, privacy, records, child-safety, food-safety, consumer or other law, or with any regulator's standard, registration condition or funding contract.
• A module or function named after a regulated activity, such as "compliance", "audit pack", "RPL", "verification" or "safety", does not mean Academyship has assessed, approved or certified that the Institution's activity complies with the relevant rules.
• Academyship does not guarantee that a regulator, funding body, employer, other education provider or other third party will accept a record, report, file or Generated Credential produced through the platform.
• Providing these modules does not make Academyship an educator, assessor, registered training organisation, credential issuer, food business operator, safeguarding, counselling or clinical service, emergency or monitoring service, or background-checking or screening service.
• Academyship does not guarantee any learning, assessment, attendance, behaviour or wellbeing outcome.

This section does not reduce Academyship's own obligations: to provide the Services with due care and skill, to meet its commitments in the Terms, the DPA and this schedule, to maintain its security measures, and to comply with the laws that apply to it. Nothing in this schedule excludes, restricts or modifies a right or remedy under the Australian Consumer Law or any other law that cannot lawfully be excluded, and Academyship will not rely on any term of this schedule in a way that would be an unfair contract term.

#07Academic administration and courses

What the module does

Where enabled, the module can be used to set up the Institution's academic structure, record applications and enrolments, manage classes, timetables and attendance, record assessments, results, progress and academic history, and import or export those records. The structure is flexible: the Institution chooses the levels and names that suit it, such as faculties, schools, departments, programs, courses, units, subjects, classes, cohorts, terms or intakes.

Institution responsibilities

• Design its academic structure, course and enrolment rules, assessment methods, grading scales and progression and completion rules, and configure them accurately.
• Ensure that only authorised and appropriately qualified staff assess, grade, moderate and approve results.
• Validate imported data before relying on it, including field mapping, duplicates, formats and totals, and keep source files until the import has been checked.
• Make all academic decisions, including admission, enrolment, progression, results, completion, misconduct and exclusion, and operate its own review and appeal processes.
• Publish its academic rules, including how results are calculated, to the students affected.
• Check results produced by a configured calculation before releasing them (section 17).

Academyship responsibilities

• Provide the configurable structures and calculation functions described in the product documentation, and apply them as the Institution configures them.
• Apply the roles and permissions the Institution sets for viewing and changing academic records.
• Show import errors that the import function detects, and provide export functions.
• Investigate and correct confirmed platform faults that cause records to be stored, calculated or displayed incorrectly, and tell the Institution as described in section 5.

Data and visibility

Records can include identity and contact details, Institution-assigned identifiers, applications, enrolments, attendance, assessment results, progress, academic history and the identity of the staff who assessed or approved a result. Staff see what their roles permit. Students see what the Institution releases to the student portal. Guardians see only what section 16 allows. Exported files leave the platform's access controls and become the Institution's responsibility.

Limits

• The platform records and calculates. It does not judge academic merit or decide whether a student has met a requirement.
• Import checks detect only some errors. Passing them does not confirm that imported data is accurate or complete.
• A calculated result is only as accurate as the rules and data the Institution configures and enters.

Corrections and disputes

Students raise disagreements about academic decisions with the Institution, through its review and appeal processes. Academyship does not decide, review or overturn academic decisions. The Institution corrects data errors, and where its record-keeping obligations require an accurate history it should record a correction and its reason rather than overwrite the original silently. Requests by individuals to access or correct their records go to the Institution, which Academyship assists (Privacy Policy section 27). Suspected platform faults go to Support (section 20).

#08Homework and group evaluation

What the module does

Where enabled, the module can be used to set homework and other tasks, receive submissions, and record evaluations, including the evaluator, mark or grade, pass result, feedback and time of evaluation. For group work, it can record a group evaluation and separate individual adjustments for group members, with reasons and notes. It can send notifications about tasks, submissions and results.

Institution responsibilities

• Set and tell students the deadline, the time zone that applies to it, accepted file types and forms of evidence, and the rules for late submission and extensions.
• Provide an alternative way to submit, or an extension, where a platform outage, accessibility barrier or technical problem prevents a student from submitting on time, and decide each case under its own rules.
• Ensure an educator reviews submissions and approves marks and feedback. Marks are entered by educators or calculated by rules the Institution configures; where an AI Feature assists, its output is decision support only (Terms section 19).
• Decide which feedback is shared with the whole group and which is individual, and check the visibility settings before releasing results. An individual adjustment and its reasons concern one student and must not be released to other group members without a lawful reason.
• Set and enforce its academic-integrity rules, including any permitted use of AI by students (Acceptable Use Policy section 11).
• Ensure it has the rights needed for the materials it distributes, and apply its own policies on students' rights in their submissions.

Academyship responsibilities

• Store submissions and evaluations, and apply the visibility settings the Institution configures.
• Send the notifications the Institution configures.
• Tell affected Institutions about service incidents in the way described on the Support page, so they can decide whether to adjust deadlines.
• Use submissions only to provide the Services. Academyship does not use Customer Data to train general-purpose AI models.

Data and visibility

Records can include submitted work and files, submission times, marks, grades, feedback, evaluator identity, group membership and individual adjustments with reasons. Educators see what their roles permit. A student sees their own submissions and the feedback released to them. Group feedback is visible to group members only when the Institution releases it to the group. There is no class-wide sharing of marks or feedback unless the Institution configures it.

Limits

• Where the module records a submission time, it is the time the platform received the submission, which may be later than when a student began uploading.
• Students should keep their own copy of submitted work. A confirmation screen or message is evidence of receipt only if it identifies the submission.
• The module does not guarantee any learning outcome, and this schedule does not state that it detects plagiarism or misconduct.

Corrections and disputes

Requests for re-marking, extensions, special consideration or academic-integrity reviews are decided by the Institution under its rules. If feedback or an adjustment is released to the wrong students, the Institution should restrict it, assess whether a privacy breach has occurred and contact Academyship if a platform fault may be involved. Notifications already delivered cannot be recalled (section 17).

#09VET, RPL and compliance

What the module does

Where enabled, the module can be used to manage training products and their versions, import or refresh training-product information from the National Register of VET (training.gov.au), manage recognition of prior learning (RPL) applications and evidence, organise compliance resources, prepare audit packs and reporting data, and record Unique Student Identifiers (USIs) where the Institution configures that field.

Institution responsibilities

• The Institution remains the registered provider. It is responsible for meeting the standards, registration conditions, funding contracts and reporting obligations that apply to it.
• Confirm that a training product is on its scope of registration before enrolling students in it or issuing certification for it. A training product appearing in the platform does not mean it is on the Institution's scope.
• Check that imported training-product information is current before relying on it, including versions, supersession, equivalence and transition or teach-out arrangements.
• Decide what to report and to whom, validate reporting data, submit it through the channel the recipient requires, and remain responsible for its content and timeliness.
• Ensure RPL decisions are made by appropriately qualified assessors, that evidence is valid, sufficient, authentic and current, and that applicants know what evidence is collected and why. Collect only the third-party and identity information that the assessment needs.
• Review audit packs before giving them to anyone, and control who receives them.
• Use information imported from the National Register, and any training and assessment resources it uploads, in accordance with the terms on which they are published or licensed.

Unique Student Identifiers

Creating a USI for a student, verifying a USI, and viewing a student's USI transcript are different actions. Each has its own requirements under the Student Identifiers Act 2014 (Cth) and the USI Registrar's processes, such as the student's permission or the notices the Registrar requires. The Institution must meet the requirements for each action it takes, whether inside or outside the platform. Storing a USI in a field does not, by itself, authorise any of those actions or any disclosure of the USI. Where a module provides a function connected with one of those actions, the Institution may use it only with the authority that action requires. A USI is a Regulated Identifier. It must not be used as an account identifier or entered into unrelated free-text fields (DPA section 8).

Academyship responsibilities

• Maintain the import, RPL, compliance-resource and audit-pack functions with due care, and investigate and correct faults in how the platform imports, stores or displays information.
• Handle USIs as Regulated Identifiers under DPA section 8, with role-based access controls.
• Not change RPL evidence, assessment decisions or reporting data except on the Institution's instructions.

Data and visibility

Records can include enrolment and outcome data, USIs, RPL evidence (which may include employment history, workplace documents, references and identity documents), assessor decisions, compliance documents and audit-pack exports. Staff see what their roles permit. Where an audit pack is provided through a time-limited download link, the link expiring does not delete the underlying records, and the generated pack is handled under the data retention information (section 18).

Limits

• Imported training-product information is a copy made at the time of import. Academyship does not warrant that it reflects the National Register at every moment.
• Reporting data produced by the platform is prepared data, not a submission. Data that passes the platform's checks may still fail a recipient's validation, and acceptance is not guaranteed.
• The module does not determine whether the Institution complies with its standards or registration conditions (section 6).
• VET record-keeping obligations, for example for assessment evidence and certification records, can extend well beyond the subscription and the post-termination export period. Section 18 explains the Institution's export and archive responsibility.

Corrections and disputes

The Institution corrects reported data through the recipient's correction or resubmission process. RPL and assessment appeals follow the Institution's own processes. If imported training-product information appears wrong, the Institution should check the National Register and tell Academyship Support if the platform's copy differs from it.

#10Certificates, letters and cards

What the module does

Where enabled, the module can be used to generate certificates, statements, letters and cards, including student identity cards, from Institution templates and data; route them for internal or external review and approval; deliver them; reissue or supersede them; and, if the Institution enables it, offer Public Verification through a link or code, such as a QR code. Where AI-assisted template review is enabled, it proposes template changes that an authorised person must approve before they are applied. An approved change may regenerate the documents produced from that template run (Responsible AI Statement).

Institution responsibilities

• Hold the authority to issue each type of Generated Credential, and issue it only when its requirements are met.
• Approve each template and the variables it uses. Templates can draw on many fields, including photographs, dates of birth, USIs, emergency contacts and health or allergy information. The Institution must include a field only where it is necessary, lawful and appropriate for a document that other people will see.
• Confirm the holder's identity and completion or eligibility before issuing.
• Use logos, accreditation marks, signatures and seals only where it is entitled to, and in accordance with their conditions of use.
• Decide whether to enable Public Verification, and tell holders in its notices what verification shows and who can see it.
• Invite external reviewers or approvers only where necessary and authorised, and end their access when the review is complete.
• Review AI-proposed template changes and the regenerated documents before issuing them. Approval does not guarantee that the content is accurate or lawful.
• Keep the register of issued credentials that the law requires of it.

Academyship responsibilities

• Generate documents from the template and data the Institution approves.
• Limit Public Verification responses to the details listed below, show the status the Institution has recorded, and take reasonable steps to protect Public Verification against misuse, such as automated guessing of links or codes.
• Not apply an AI-proposed change without the approval of an authorised person.
• Not present a Generated Credential as endorsed or verified by Academyship.

Data and visibility

Where the Institution enables Public Verification, anyone holding a valid verification link or code can see limited credential details without signing in: the holder's name, the credential number and type, the course, the issue date, the issuing Institution, and the credential's current status. This is not a searchable public profile: it cannot be used to search for a person or to browse an Institution's credentials, and it does not display the other fields in the template. Anything printed on a credential or card is visible to anyone who sees the document itself.

External reviewers and approvers see the documents and fields presented to them for review while their access lasts. Delivered, downloaded and printed copies are outside the platform's control.

Limits

• Design features such as QR codes, microtext, watermarks and serial numbers can help to detect alteration. They do not guarantee authenticity or prevent forgery.
• Public Verification confirms what the Institution's record shows. It does not confirm that the person presenting a document is the holder.
• A Generated Credential does not prove regulatory recognition or accreditation, and it does not show that Academyship checked the achievement.
• Verification links can be forwarded. Disabling verification or superseding a credential affects later checks, not copies already downloaded, printed or shared.

Corrections and disputes

The Institution corrects a Generated Credential by reissuing, superseding or revoking it under its own processes and the law that applies to it, rather than silently editing a document already issued. It keeps the issuance history its obligations require, so that verification shows an accurate status. Holders raise errors with the Institution. Requests to remove or limit a verification record go to the Institution first; if the Institution cannot be reached, or the concern is about Academyship's own handling, contact privacy@academyship.com.au. Platform faults in verification go to Support.

#11Behaviour and wellbeing

What the module does

Where enabled, the module can be used to record behaviour incidents (the student, date, reporting staff member, type and remarks), points, rewards and redemptions, goals and interventions (descriptions, targets, progress and follow-up notes), and evidence files. The Institution can configure notification rules, including thresholds for negative points or incidents, the staff, students or Guardians who receive a notification, and its template.

Institution responsibilities

• Keep records factual, relevant and proportionate. Distinguish what was observed from what was alleged and from opinion, record the source, and avoid labels.
• Treat an allegation as an allegation until it has been determined, apply procedural fairness, and record the outcome.
• Record health, disability, counselling or other welfare information only where necessary, only in fields restricted to staff who need it, and not in general remarks.
• Decide which notes are internal to staff and which may be shared with the student or Guardians, configure visibility accordingly, and check before anything is released.
• Attach only evidence that is needed. Never upload suspected illegal material; follow the Child Safety Statement instead.
• Apply the Guardian rules in section 16 before sharing records or enabling Guardian notifications, including custody and safeguarding restrictions and the rights of Adult Learners.
• Ensure that every disciplinary, welfare or support decision is made by an authorised person. Points and thresholds are prompts, not decisions.
• Meet its own safeguarding, duty-of-care, mandatory-reporting and emergency obligations (Terms section 12).

Automatic threshold notifications

Automatic notifications to students and Guardians, for example when a student reaches a points threshold, are off until the Institution turns them on. The Institution decides whether to turn them on, the thresholds that trigger them, who receives them and what they say. Before turning on notifications to students or Guardians, the Institution should consider whether automatic delivery is appropriate for the students concerned, keep the content brief and free of sensitive detail, and confirm that each recipient is entitled to receive it.

Academyship responsibilities

• Store records and apply the visibility and role settings the Institution configures.
• Send notifications according to the rules, recipients and templates the Institution configures.
• Respond to platform-related child-safety reports as described in the Child Safety Statement.

Points totals and thresholds are Rule-based Processes set by the Institution. They are not AI scoring. Academyship does not use AI for automated wellbeing, health or behavioural scoring of children.

Data and visibility

Records can include incidents, allegations, remarks, points, rewards, goals, interventions, follow-up notes, evidence files and notification history. Some of this may be Sensitive Information, or may reveal it. Authorised staff see what their roles permit. Students and Guardians see only what the Institution has decided to share with them. A notification sent by email or SMS leaves the platform and may be read on a shared device or account.

Limits

• The module is not an emergency, monitoring, triage or clinical service. Academyship does not watch records or notifications as they are created, and does not assess risk to any student.
• Email and SMS delivery is not guaranteed. Do not rely on a notification for anything urgent. If someone is in immediate danger, call 000.
• A points total or threshold is not a finding of misconduct.

Corrections and disputes

A student or Guardian who disagrees with a record can ask the Institution to review it. The Institution should correct it, add the outcome, or, where the law gives the person that right, attach their statement. Where an allegation is not substantiated, the Institution should record that outcome and consider whether the record should remain visible to anyone beyond those who need it. A notification sent in error cannot be recalled. The Institution should contact the recipient and assess whether a privacy breach has occurred.

#12Bookings and events

What the module does

Where enabled, the booking functions can be used for appointments and sessions, such as interviews, tours and meetings, including through public booking forms and invitations to parents. They can place temporary holds, confirm bookings, manage waitlists, cancellations and reminders, and record the booking person's name, email address and phone number and any association with a student or Guardian. The event functions can publish calendar events with descriptions, locations or online meeting links, attachments, recurrence, visibility settings, capacity, tags, RSVPs, comments and reminders, and keep a history of changes. Users can choose to add a booking or event to an external calendar through Google, Outlook or Office 365, or Yahoo links, or through an ICS calendar file or link.

Institution responsibilities

• Set and publish eligibility, capacity, duration, time zone, cancellation, rescheduling and no-show rules.
• Make clear that a temporary hold is not a confirmed booking, how long a hold lasts, how waitlist offers are made and when an offer expires.
• Give a collection notice on public booking forms, ask only for the information the booking needs, and obtain any marketing permission separately from what the service requires.
• Choose each event's audience and visibility, moderate comments, share online meeting links only with the intended audience, and attach only appropriate files.
• Supervise events and appointments and keep them safe, including applying its safeguarding rules to one-to-one meetings with children (Child Safety Statement section 10).
• Give important changes directly. Do not rely on a reminder as the only notice of a change or cancellation.

Academyship responsibilities

• Apply capacity, hold, waitlist and eligibility settings as documented and configured.
• Create a calendar link or file only when a User chooses to.
• Send the reminders the Institution configures, and keep event history where the module records it.

Data and visibility

Records can include booking contact details, student or Guardian associations, appointment details, holds, waitlist positions, confirmations, cancellations, RSVPs, comments and event history. Staff see what their roles permit; other Users see the events and comments shown to their audience. A calendar link or file sends the selected event details, such as the title, time, location and description, to the calendar provider the User chooses. That provider is not an Academyship Subprocessor, and the link is not an account connection between Academyship and the provider. A copy in an external calendar may not change or disappear when the booking changes or is cancelled. Public booking forms may use browser storage to carry details between steps while a booking is completed. Browser storage is explained in the Cookie Policy.

Limits

• A hold reserves a place only for the period shown. A booking is confirmed only when the confirmation is shown or sent.
• Reminder delivery is not guaranteed.
• The module records attendance and RSVPs. It does not supervise anyone.

Corrections and disputes

Disputes about eligibility, cancellations, no-show consequences or any fee are decided by the Institution. Any booking or event fee is an Institution Charge (section 19). Users remove external calendar copies themselves. Platform faults go to Support.

#13Library

What the module does

Where enabled, the module can be used to manage a catalogue, loans (issue, due and return dates), reservations, renewals, reminders, fines with payment status and receipts, borrower identity and contact details, and ratings and reviews linked to a User and a loan.

Institution responsibilities

• Set and publish loan eligibility, limits, loan periods, renewals and extensions, reservation priority, and the process for lost and damaged items.
• Decide whether fines apply, set lawful and proportionate amounts, and provide waivers and a dispute process. Fines are Institution Charges (section 19).
• Treat borrowing history as personal information that can reveal a person's interests, beliefs or circumstances. Restrict staff access to it, do not disclose it to other students, and share it with Guardians only where authorised and appropriate.
• Keep reminder content minimal, especially where reminders go to Guardians or shared accounts. A title on a reminder can reveal what someone is reading.
• Moderate reviews: remove unlawful, abusive or infringing content, decide whether reviewer names are shown, and ensure reviews do not reproduce substantial copyright text.
• Not withhold a record that the law requires it to give or make available, such as a person's access to their own personal information, solely because of an outstanding fine or unreturned item. Any hold it applies to services or records must be consistent with law and its published policies.

Academyship responsibilities

• Calculate fines and send reminders according to the Institution's settings.
• Apply the review-visibility and role settings the Institution configures.
• Use borrowing information only to provide the Services, never for advertising.

Data and visibility

Records can include borrower identity and contact details, loans, reservations, due and return dates, fines, payment status, receipts, reminders, and ratings and reviews. Borrowing records identify the borrower; they are not anonymous usage data. Library staff see what their roles permit. Students see their own loans and fines where the Institution makes them available in the portal. Reviews are visible to the audience the Institution configures.

Limits

• A fine calculation depends on the Institution's settings and on returns being recorded accurately.
• A status of "paid" recorded in the library module is not proof that funds have settled. Payment processing and reconciliation are covered in section 19.
• Reminder delivery is not guaranteed.

Corrections and disputes

Disputes about returns, damage, fines or waivers are decided by the Institution. Requests to remove a review go to the Institution, which moderates under its rules. Academyship may act on reviews that breach the Acceptable Use Policy. Platform faults, such as an incorrect calculation under the configured rules, go to Support.

#14Canteen

What the module does

Where enabled, the module can be used to publish menus, take orders (including special instructions and collection or delivery details), manage meal plans and subscriptions, record dietary and other restrictions for students, and link student cards by card number or card identifier. Wallet balances, spending limits, top-ups, transfers and other payment matters are covered by section 19.

Institution responsibilities

• The Institution, or the canteen operator it engages, is responsible for food safety, allergen management, labelling, stock, preparation, delivery and supervision at collection.
• If a third-party operator runs the canteen, the Institution is responsible for that arrangement and for the access it gives the operator's staff. They use the platform as Users authorised by the Institution, not as Academyship Subprocessors.
• Collect dietary and allergy information accurately, with the student or Guardian as appropriate; keep it current; and restrict it to the people who need it. It may be health information, and some dietary details can reveal religious or cultural background.
• Keep each student's medical or anaphylaxis action plan, and emergency contacts, available outside the canteen module. The module is not a medical plan.
• Set and publish meal-plan rules, including renewal, cancellation, missed collection, substitutions, unavailable items and refunds.
• Decide which Guardians may order, approve meal plans or set limits for a student, under section 16, and whether a student may order without Guardian approval.
• Maintain a workable fallback for serving students with dietary needs if the platform or network is unavailable.

Academyship responsibilities

• Record orders and display restriction information to the roles the Institution configures.
• Apply ordering restrictions where the module offers that function and the Institution has configured it.
• Academyship does not prepare, handle, sell or deliver food.

Data and visibility

Records can include orders, special instructions, collection details, meal plans, dietary and allergy restrictions, and card numbers or identifiers. Canteen staff and operator staff see what their roles permit. Guardians see what section 16 allows. A student card number or identifier is a campus identifier, not a bank card. A meal subscription is an Institution service, not an Academyship subscription.

Limits

• Menu and stock information is only as accurate as the Institution or operator keeps it.
• Orders depend on network and platform availability.

Corrections and disputes

Problems with an order, missed collection or meal-plan refund are handled by the Institution or its operator. Students and Guardians ask the Institution to update dietary information. Payment, wallet and card-transaction disputes follow section 19. Platform faults go to Support.

#15Front office

What the module does

Where enabled, the module can be used to sign visitors in and out (recording contact details, any identification details the Institution chooses to record, purpose, times, notes and a photograph), and to record enquiries from prospective students and others, call logs (contact, duration, description and follow-up), complaints (contact, description, actions, assignee, notes and images), and correspondence, including postal and courier records. Call logs are records of call details and notes entered by staff, not audio recordings.

Institution responsibilities

• Decide whether a visitor's identification is needed for the visit, and collect it proportionately. Where sighting a document is enough, do not copy it. Record only what is needed, such as the document type, rather than a full number or image, unless the law or a genuine need requires more.
• Give visitors, enquirers and complainants a collection notice, and keep marketing permission separate from service follow-up.
• Carry out Working with Children Checks, other screening and supervision through its own processes. Signing a visitor in does not mean the visitor has been screened or cleared.
• Keep premises safe, and have an alternative to the visitor log for emergencies if the platform or network is unavailable.
• Handle complaints under its own complaints process: protect complainants, restrict access to complaint records and evidence, and avoid assigning a complaint to the person complained about. Refer complaints about Academyship to Academyship.
• Send correspondence only to authorised recipients. If it records calls with another system, meet that system's notice and consent obligations.

Academyship responsibilities

• Store front-office records and apply the role settings the Institution configures.
• Academyship does not verify visitors' identities, check them against any register, or screen them.

Data and visibility

Records can include names, contact details, identification details or images, photographs, visit purposes and times, enquiry details, call details and notes, complaint descriptions and evidence, and correspondence records. Front-office staff see what their roles permit. Complaint records should be limited to the people handling the complaint.

Limits

• The visitor log shows only who has been signed in and out. It may be incomplete if people are not signed in or out.

Corrections and disputes

Visitors, enquirers and complainants ask the Institution to access or correct their records. Complaint outcomes are decided by the Institution. Complaints about Academyship go to Academyship's complaints process.

#16Portals and roles

What the module does

Where enabled, the platform provides student and Guardian portals, invitations to those portals (with the invited contact and an expiring invitation link), sign-in records (including time, IP address and browser or device information), and staff and portal roles that control access to each module.

Institution responsibilities

• Authorise every account, and send invitations only to a contact it has confirmed belongs to the intended person.
• Before linking a Guardian, confirm the person's identity and their authority for that student. A linked Guardian sees only what the Institution has authorised for that relationship. A family relationship or matching email address is not proof of authority.
• Record and apply custody orders, safeguarding restrictions and other limits before linking a Guardian or enabling Guardian notifications, and review the link when circumstances change.
• Respect Adult Learners' own rights. Review Guardian access when a student becomes an adult, and do not give Guardians access to an Adult Learner's records without a lawful basis.
• Take care with shared contact details, such as a family email address used by more than one person, because invitations and notifications sent there may be read by others.
• Design roles on a least-privilege basis, review them periodically, and do not rely on default role settings without checking them.
• Remove or change access promptly when staff leave or change roles, when students finish or withdraw, and when a Guardian relationship changes, and revoke unused invitations.
• Restrict export permissions. Exported files are outside the platform's access controls.
• Tell Users to sign out of shared devices and not to save sign-in details on them.
• Ask Users to stop and report any information they can see but should not, investigate those reports, and tell Academyship if a platform fault may be involved.

Academyship responsibilities

• Enforce the roles, permissions and Guardian links the Institution configures, and maintain the security measures in DPA Annex II.
• Keep sign-in records for security and audit purposes, under the data retention information (section 18).
• Investigate reports of incorrect access that may involve the platform, and notify the Institution of a Personal Data Breach under DPA section 17.

Academyship does not decide who is a Guardian and does not verify family relationships or custody arrangements.

Data and visibility

Records can include portal accounts, invitation details, sign-in records with IP address and browser or device information, role assignments and permission changes. Institution administrators see what their roles permit. Retention periods differ by dataset and are described in the data retention information.

Limits

• The platform applies the access the Institution configures. It cannot tell whether that access is lawful or appropriate for a particular family.
• Removing access stops future access through the platform. It does not retrieve information already viewed, downloaded or sent.

Corrections and disputes

If a Guardian is linked wrongly, or a User has access they should not have, the Institution should remove the access immediately, work out what was seen or sent, and assess whether a notifiable data breach has occurred. Academyship cooperates under the DPA. Individuals raise access concerns with the Institution, or with Academyship at privacy@academyship.com.au or security@academyship.com.au where the concern involves the platform.

#17Rule-based processes and notifications

Several modules use Rule-based Processes that can affect people even though they do not use AI. The Institution chooses and tests the rules, explains them to the people affected where the law requires, and makes sure a person can question an outcome. Privacy law changes that apply from 10 December 2026 may require an Institution's privacy policy to explain when computer programs make, or substantially help to make, decisions that significantly affect individuals. Academyship will provide reasonable information about how a module's Rule-based Processes operate, to help the Institution meet those obligations.

Notifications and copies outside the platform

Emails, SMS messages, push and lock-screen previews, exports, PDFs, printed cards, calendar files and links can carry information beyond the platform's access controls, and can be read by anyone with access to the receiving device or account. Restricting or withdrawing access in the platform does not retrieve a copy already delivered. The Institution should keep notification templates brief, avoid Sensitive Information and Regulated Identifiers in them, and check recipients before enabling automatic notifications. Email and SMS delivery depends on providers and networks and is not guaranteed (Terms section 7B).

#18Exports, copies and records retention

During the subscription, authorised administrators can export Institutional Records through Academyship's export functions. When an Institution leaves, it can export all of its records, including attachments, audit trails and signing evidence, in commonly used formats. After termination or expiry, Academyship makes Customer Data available for authorised export for at least 60 days, then deletes it as described in Terms section 23 and DPA section 20. The Institution should test its exports early and check that they are complete and readable before the export period ends.

An Institution's legal obligations to keep records, for example school records, public records, VET assessment evidence and certification records, can last many years after a student finishes and well beyond the subscription and the export period. Unless an Order Form provides a separately agreed hosted-retention or archive service, Academyship does not keep Customer Data after the export period to meet those obligations. The Institution is responsible for exporting, archiving and keeping accessible the records it must retain, and for planning continuity if it changes provider or ceases to operate.

Public Verification depends on the Institution's records remaining in the platform. When those records are deleted after termination, or the Institution disables verification, existing links stop confirming credentials. The Institution should plan how it will verify credentials after that.

A time-limited download link expiring is not deletion of the underlying records, and a backup copy expiring is not deletion from active systems. Copies already sent to or downloaded by others, including Guardians, External Recipients, calendar providers and printed documents, are outside Academyship's deletion control; Academyship still deletes the copies it controls. Dataset-specific retention is described in the data retention information. The Institution should tell Academyship about any legal hold that should prevent deletion.

#19Payments connected with these modules

Library fines, canteen orders, meal plans and booking or event fees are Institution Charges, not Fees. Canteen wallet balances, top-ups and transfers are not Fees either. Where an Institution uses Academyship's payment or wallet features for any of these, the Payments and Wallets Schedule governs payment authorisation, methods, wallet balances, refunds, disputes and related matters, to the extent it applies to the Institution. This schedule does not govern those matters.

• A person who pays an Institution Charge does not thereby buy Academyship's services.
• A status recorded in a module, such as "paid", "refunded" or "waived", is different from a payment that has settled.
• Where an Institution collects Institution Charges outside Academyship, the module records only what the Institution enters.
• The Institution must not impose fees or surcharges that the law or card scheme rules prohibit.

#20Support, faults, complaints and disputes

The Institution handles its own decisions. Academyship handles faults in its platform and its own obligations. Urgent safety and privacy matters should go to every relevant place at once, not be passed between inboxes.

No one needs to complete an Institution's or Academyship's internal process before calling emergency services, contacting police or a child-protection authority, complaining to a regulator such as the Office of the Australian Information Commissioner, or getting legal advice.

#21Changes to this schedule

Each version of this schedule has a version number and effective date. Publishing a new version on this website does not, by itself, change the version that applies to an Institution. A new version applies to an Institution only:

1. when the Institution accepts it through an Order Form or the institutional acceptance process;
2. from the start of the Institution's next renewal term, after Academyship has given reasonable advance notice of the new version and its changes, consistent with Terms section 31; or
3. earlier, after notice, to the extent a change is required by law or necessary to address an urgent security risk.

No version applies retrospectively. Prior versions can be requested from legal@academyship.com.au.

#22Related documents and change history

Terms of Service Data Processing Addendum Acceptable Use Policy Payments and Wallets Schedule Privacy Policy Child Safety Statement Responsible AI Statement Data Retention Complaints Student Privacy Guide Cookie Policy Support