> 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/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.

# Academic approval

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](/credit-outcomes) 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.

> **Note**
>
> 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.

> **Note**
>
> 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. |

> **Note**
>
> **`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](/detecting-changes) like any other change.

```json
{
  "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](/detecting-changes) 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.