25 September 2026

Nothing this week needs anything from you. The one API change is a new optional field, and an integration that ignores it behaves exactly as it does today.

Institution API

Specialisations on an application

An application can now record the majors, minors, honours streams and research areas an applicant is taking alongside their program.

Send them on submit as handbook codes:

{
  "applicant": { "givenName1": "Tam", "familyName": "Nguyen", "dob": "2004-03-11",
                 "emailAddress": "t.nguyen@student.example.edu.au" },
  "programCode": "3409",
  "year": 2026,
  "stream": "DOMESTIC_FP",
  "specialisations": ["SOCAE1", "THSTC1"]
}

Codes alone, not code-and-year pairs. They are read in the application’s own year, the same handbook year programCode is read in, so this is the shape you already send. A code the catalogue does not hold for that year is a 400 naming it.

GET /institution/applications/{id} returns them with the catalogue’s own words:

"specialisations": [
  { "code": "SOCAE1", "year": 2026, "name": "Sociology", "type": "Major" },
  { "code": "THSTC1", "year": 2026, "name": "Theatre and Performance Studies", "type": "Minor" }
]

name and type come from the catalogue and are null if we no longer hold that specialisation. code and year are what the application recorded, so a withdrawn specialisation still reads as a code rather than as nothing.

Correct them with a merge patch. specialisations replaces the whole set the way sources does, so send them all to change one:

{ "specialisations": ["SOCAE1"] }

An empty array or null removes them. Unlike programCode, year and stream, this is not refused after an assessment has run: nothing is assessed against a specialisation, so correcting one leaves the credit already granted true. Same reasoning as intakeCode.

The field is optional everywhere and an application without any is completely normal — most programs offer none. Two is the usual maximum and the applicant portal holds to it, but this endpoint does not: what you send is what happened.

Management Portal

Cognate rules

The RPL checksheets are now data rather than a set of spreadsheets. RPL → Cognate Rules holds a ruleset per program area, each a set of rules an officer can read and edit: the qualifications a rule tests, the AQF level, discipline, completion and recency it asks for, and the outcome it grants.

The lists a rule tests against are managed in the same place. A list carries three flags — whether it is cognate, whether it can decide a match on its own, and whether it always needs an officer’s attention — and anything marked not cognate is automatically held for a person rather than deciding alone.

The 26 checksheets are loaded: 190 rules over 259 conditions, and 59 lists. Several of them carry questions we would like answered, and those are the ones an officer will find flagged for attention.

Editing a program’s structure

A program’s or a specialisation’s curriculum can now be built and corrected in the portal, on the Curriculum tab, rather than only arriving with the handbook.

Two tabs, because the two jobs are different:

• Root structure is the shape. Add a structure under the program, nest one inside another, and attach a specialisation the program offers.
• Structures is the flat list of every structure, and where courses go into one.

A structure carries its title, its note and its rule, and a specialisation attached to a program shows as a pointer rather than repeating its whole subtree — its own page is where that lives.

Specialisations in the catalogue

Catalogue → Specialisations lists the majors, minors, honours streams and research areas alongside programs and courses, searchable by code, name, type and year, with a detail page for each. Most arrive with the handbook; one can be added here when it has not.

The Programs list and detail page now read the same way, and a program’s code and year are locked once it exists, since they are its identity rather than fields.

Specialisations on an application

Officers record what an applicant is taking on both screens that create or correct an application — New application, and the application’s own Overview. The picker offers only what the chosen program’s curriculum lists, grouped into its majors and minors, and stops at two.

RPL on a program

A program’s RPL tab now links to the credit agreements and cognate rulesets that apply to it. The credit rules that were there are unchanged and still reachable; we are settling what belongs on that tab before putting them back.

Applicant Portal

Choosing specialisations

An applicant picks their majors and minors on the same screen as their program and intake, because a specialisation is part of what they are applying for rather than another question in the form. Up to two, and the picker only appears for a program that offers any.

It changes what comes next. Nominating courses for credit used to offer everything the program references, which for a large program is several hundred courses and mostly the wrong ones. Narrowed to what the applicant is actually taking, one program goes from 696 courses to 59.

Declarations

A form can now ask an applicant to agree to things before submitting. Application Portal → Forms takes a Declarations step, and you write as many separate tick boxes on it as you need, marking the ones that must be ticked. An applicant cannot move past the step until the required ones are.

Smaller things

• A course can only be nominated once. The picker leaves out what is already on the list, and a code typed by hand is refused if it is already there.
• The form is wider and reads at a larger size, and its fields are spaced further apart. It is filled in once, often on a phone, often by somebody who has not seen it before.