Credit scenarios
Ready-to-post request bodies, each producing a different shape of credit decision. POST any of them
to /institution/applications and read the result from
/institution/applications/{id}/outcome.
Each body carries a fixed sourceRef, so re-sending one is a 409 rather than a duplicate.
Several subjects, several units
Four courses satisfy one credit mapping together, and that single decision awards two units. This is the case a flat one-source-one-unit model cannot represent.
Result: 36 UOC, workflowStatus: DECIDED.
Request body
Two subjects for one unit
An internal rule, not a mapping. The macroeconomics rule requires two subjects when neither is intermediate, so both are consumed for one unit and both appear in sources.
Result: 6 UOC, workflowStatus: DECIDED.
Request body
The same unit awarded twice
One subject satisfies two different mappings that both award MATH6306. Both grant. The unit appears twice under different decisionIds, and totalCreditUoc counts it twice.
This is deliberate. Collapsing the two would take a unit off one mapping and misreport both, so the clash is surfaced and routed to a credit officer instead. finalOutcome stays false until they decide — which is exactly why you should not treat a non-final total as an answer.
Result: 18 UOC for 12 UOC of distinct units, workflowStatus: CREDIT_TEAM_REVIEW.
