Academic approval | UAC | Documentation

Credit awarded by the assessment pipeline is approved. It counts, and in most cases nobody else is asked.

Each decision is also paired with the academic staff responsible for that credit — a record of who would rule on it if anyone needed them to. The UAC credit team reviews the credit and may adjust it, refuse it, or escalate it to that academic when they would rather not make the call themselves.

This is internal to UAC and UNSW — there is nothing for you to call. It is documented here because an escalation changes what the outcome endpoint is telling you, and that does affect you: while a decision is outstanding the total can still fall, and once an academic has answered it cannot.

Pairing, and who it lands on

Pairing works per decision, not per unit. Several units awarded together by one credit mapping are one decision and are answered once — the same grouping the outcome response exposes as decisionId.

Responsibility is resolved in a fixed order:

The course’s own authority

If the course being credited has academic staff assigned to it — either everywhere or within this particular program — they are paired with it.

The program’s authority

Otherwise the program’s own authority is. This is also where a decision goes when its several units would resolve to different people: rather than splitting one decision, it goes up to the program.

The credit team

Where no authority is configured, there is no pairing and the credit team’s own decision stands — though they can still escalate it to somebody they name. See below.

Where more than one authority is responsible, any one of them may answer. It is one decision, answered once.

A pairing on its own changes nothing. The credit is approved, it counts towards the total, and no one is waiting. Only an escalation asks anybody a question.

A pairing is a suggestion, not a routing rule

Escalation is not limited to whoever a decision is paired with, and does not require a pairing at all.

When the credit team escalates, they either send it to the paired authority — the normal case, and what the dialog offers first — or choose somebody else. Where the cascade found nobody, they choose from the institution’s configured authorities. Either way the record notes that the escalation was the credit team’s own choice rather than the cascade’s.

This matters for reading an outcome: awaitingAuthority can become true on credit that was never paired with anyone. Do not treat the absence of a pairing as a guarantee that a decision will never go to an academic — there is no field for the pairing, and it would not tell you this even if there were.

Nothing here changes what you send us or what you read back. It is documented because “no authority is configured for this programme” is not the same as “this credit cannot end up waiting on one”, and the two are easy to conflate.

What an escalation does to the outcome

Two fields tell you where a decision stands.

awaitingAuthority on the outcome is true while any of its credit is waiting on an academic. That credit is counted in totalCreditUoc — it stands unless the academic refuses it — so while this flag is true the total can still fall. finalOutcome is false whenever it is true.

authorityState on each credit says which ones, and what happened:

Value	Meaning
`null`	Nobody was asked. The normal case: the credit is approved as matched and the credit team decides it.
`awaiting`	Escalated and not yet answered. Counted in the total, and it could still be refused.
`confirmed`	The academic agreed. It stands, and no figure changed.
`refused`	The academic rejected it. `uoc` is `0`, `status` is `rejected`, and `assessedUoc` says what it would have been.

confirmed and refused are settled. Once an academic has answered, the credit team cannot change that decision — not the units, not an exemption, not a reversal. So a credit reading confirmed or refused will not move again, and you can store it as final. Only awaiting can still change.

If a decision genuinely has to be revisited, a new one is escalated rather than the old one edited, and that appears in the change feed like any other change.

{
  "totalCreditUoc": 12,
  "finalOutcome": false,
  "awaitingAuthority": true,
  "credits": [
    { "targetUnitCode": "ECON5248", "uoc": 6, "status": "granted", "authorityState": "awaiting" },
    { "targetUnitCode": "ECON6202", "uoc": 6, "status": "granted", "authorityState": null }
  ]
}

An application holds at CREDIT_TEAM_REVIEW while an escalation is outstanding, and the credit team’s own approval cannot be given until it is answered. So finalOutcome: true still means academic approval is settled — there just usually isn’t any to settle.

If you are storing outcomes rather than reading them live, the change feed is the safer basis: an application whose credit changes after an academic answers appears again with its new figures, so re-reading the feed converges on the right answer without you having to track escalations yourself. awaitingAuthority is the cheaper signal if you only want to know whether to come back.

What is not exposed

Deliberately, for now:

who a decision is paired with, or was escalated to
when an answer is expected

If either would change what you build, tell us — the data exists, and exposing it is a question of agreeing the shape rather than of collecting it.