> For clean Markdown of any page, append .md to the page URL.
> For a complete documentation index, see https://docs-unsw-v6.advance-uac.com/releases/2026-09-11/llms.txt.
> For AI client integration (Claude Code, Cursor, etc.), connect to the MCP server at https://docs-unsw-v6.advance-uac.com/_mcp/server.

# 11 September 2026

## Management Portal

### A space for academic authorities

Academic staff who rule on credit now have their own area of the portal, opened by the
`advance_institution_academic_authority` role. It has three parts:

* a **dashboard** of the applications escalated to them, longest wait first
* **applications**, where they read every credit decision on an application but act only on
  the ones escalated to them, and can award credit themselves
* **RPL** — credit agreements, mappings and rules, narrowed to their own programs

An academic sees nothing of the credit team's screens, and nothing belonging to a program
they are not responsible for.

### Awarded credit is approved and paired, not pending

Credit the assessment pipeline awards is **approved**. It is also *paired* with the academic
responsible for it, but a pairing asks nobody anything, so configuring an authority no longer
holds up the applications it touches.

The credit team reviews the credit and chooses: change the units, approve it provisionally,
mark it exempt, reject it, or **escalate** it to an academic when they would rather not make
the call. Only an escalation makes anything wait. Manual credit an officer creates can be
escalated the same way.

### An academic's answer is final

Once an academic has accepted or rejected a credit decision, the credit team cannot change
it — no re-pricing, no exempting, no rejecting, and no editing or withdrawing escalated manual
credit. If a decision genuinely has to be revisited, the way back is to escalate a new one.

This is the point of escalating at all. An answer the credit team could quietly overturn
afterwards is not one worth asking for, and the record would otherwise show an academic's name
against a figure they never agreed to.

### Working by intake

An application now records the intake the applicant is starting, picked from your own intake
schedule, and officers work applications in intake order — the term beginning in a fortnight
before one eighteen months out. It appears on the applications list as a sortable column, on
the application itself, and on the create form. **Intakes** under Configuration lists every
intake we hold for you, with its start and end dates and whether it is upcoming, running or
finished.

### Searching the subject catalogue

Naming a UNSW course as the credit being granted meant typing its code, its title and
its credit points by hand, out of the handbook. The code field now searches the subject
catalogue: type part of a code or part of a name, and picking a subject fills in the
other two.

It works when authoring a credit mapping and when a credit officer awards credit
manually against an application.

Codes we have not loaded can still be typed in. The catalogue we hold is a snapshot of
one year, and credit mappings outlive it — of the target course codes in the mappings
today, around one in seven names a subject that is not in it. So the search assists
typing rather than replacing it.

> **Note**
>
> Credit **agreements** are the exception, and deliberately: an articulation names one
> target program, so its target codes stay restricted to that program's own units and
> are chosen from a list rather than searched.

### Smaller things

* **Applications** leads with the applicant's name rather than the program code, which was
  identical on every row, and has a search across applicant, program, intake, status and any
  of your references. Program and cohort are one column now, and the row actions are buttons.
* **Applicant details** was rebuilt to match the layout of the application page, and an
  applicant's name links through to it from the applicants list.
* **Several of your references** can be recorded and edited wherever an applicant or an
  application is created or corrected, not just one.
* Rejected credit sits in its own section on the Result tab, so what was granted reads
  cleanly.

## Institution API

### Several references per record

An applicant or an application can now carry **one reference per system of record** rather
than one in total. Send them as `sources`, in the order you want:

```json
{
  "sources": [
    { "sourceName": "SITS", "sourceRef": "z1234567" },
    { "sourceName": "TRIM", "sourceRef": "T-99814" }
  ]
}
```

Accepted on create and on `PATCH`, and returned on every applicant and application response.
`sources` replaces the whole set, so an entry you leave out is removed and `[]` clears them;
omitting the field leaves every reference alone. The first entry is the primary — what list
views, search results and the change feed show. [Details](/corrections#correcting-the-references).

> **Note**
>
> **Nothing you have built needs to change.** The single `sourceName` /
> `sourceRef` pair is still accepted everywhere it was and still returned on
> every response, where it now reports the first of `sources`. Sending the pair
> on a `PATCH` edits that first reference and leaves any others alone.

Two behaviours are stricter, both of them fixes:

* **Submitting a duplicate reference is now refused.** The check used to look only at a
  record's primary reference, so an application quoting a `sourceRef` we already held against
  a second system got through and created a duplicate. It is now a `409` naming the record
  that holds it.
* **References sent with an applicant we already know are kept.** If we match your applicant
  on name and date of birth rather than on a reference, the references you sent are added to
  that applicant instead of being discarded.

### The intake an application is for

`intakeCode` on submit and on `PATCH` records the term the applicant is starting, using your
own code for it:

```json
{ "intakeCode": "5269" }
```

Responses carry `intakeCode` and `intake`, the intake's name:

```json
{
  "intakeCode": "5269",
  "intake": "Term 3 2026"
}
```

These are your term codes, loaded from the intake schedule you supply us, so a code you use is
a code we hold; one we do not recognise is a `400` naming it. Optional, but worth sending —
our officers work applications in intake order, and one with no intake cannot be prioritised
against the rest.

> **Note**
>
> **Nothing you have built needs to change.** Omit the field and the application simply has no
> intake, exactly as before.

Unlike `programCode`, `year` and `stream`, the intake can still be corrected after an
application has been assessed: nothing is assessed against it, so changing it leaves the
credit already granted true. It is also **not** the commencement year — `year` picks the
programme and the credit rules, `intakeCode` says which term the applicant starts, and an
application sent in 2026 for Summer Term 2027 has both.
[Details](/corrections#the-intake).

### Provisional credit

`provisional: true` on a credit marks it approved but conditional — the applicant receives it
once they have completed the further study `note` describes, usually a year later.

It counts. `status` stays `granted`, `uoc` is what it is worth, and `totalCreditUoc` includes
it, because it stands unless the condition is not met. A separate field rather than a fourth
`status` value, so this credit still reads as `granted` to anything written before it existed.

Read it when you are telling an applicant what they hold today; ignore it when you are
reconciling totals. [Details](/credit-outcomes#credit-the-applicant-does-not-have-yet).

### Academic approval: escalation, and two new outcome fields

Credit the pipeline awards is **approved**. It is also paired with the academic staff
responsible for it, but a pairing asks nobody anything — the credit team reviews the credit
and escalates a decision only when they would rather an academic ruled on it.

Two fields tell you when that has happened:

* **`awaitingAuthority`** on the outcome — true while any of its credit is waiting on an
  academic. That credit is counted in `totalCreditUoc`, because it stands unless refused, so
  while this is true the total can still fall. `finalOutcome` is false whenever it is true.
* **`authorityState`** on each credit — `awaiting`, `confirmed`, `refused`, or `null` for the
  normal case where nobody was asked.

A refused decision reports `uoc: 0` and `status: rejected`, with `assessedUoc` carrying what
it would have been worth.

> **Note**
>
> The caveat published with the [2 September release](/releases/2026-09-02) is
> resolved. `finalOutcome: true` means academic approval is settled, and a
> refusal is excluded from the total. If you read that release's warning,
> `awaitingAuthority` is now the field that answers it directly.

[Details](/academic-approval).

> What changed in this week's release