ADR: Programme Progress Remediation Semantics

Status: Draft

Context

Programme progress is currently updated when a submission is created. Correction Batches (remediation) can change scores/outcomes after the fact. We need consistent rules for when programme requirements/enrolments should update in response to remediation.

Decision

1. Monotonic met:

   • If a requirement is met, remediation may only keep it met or upgrade missing metadata; it must not revert to pending/failed unless an explicit “reopen” flag is passed.

2. Reopen on downgrade (opt-in):

   • When a remediation lowers a submission’s outcome below the requirement, we only reopen the requirement if the batch is marked reopenProgrammeProgress=true (future optional flag). Default is to keep met stable to avoid surprise downgrades.

3. Upgrade on improvement:

   • If remediation upgrades a submission so that a previously pending/failed requirement now meets the rule, we set it to met, update submission_id, attempt_count, completed_at, and re-evaluate enrolment completion.

4. Source of truth:

   • Use submission_score_versions.latest (via submissions.latest_score_version) when available; otherwise fall back to current submission fields. Programme updates should run after correction batch application.

5. Enrolment completion:

   • On any requirement status change triggered by remediation, recompute pending mandatory requirements and mark enrolment completed (and issue certificate) if none remain.

Consequences

• No surprise downgrades by default; reopen is explicit.
• Corrections that improve scores can complete requirements/enrolments retroactively.
• Programme listener must be invoked from correction batch application with access to updated score/outcome.

Alternatives Considered

• Automatic downgrade on any score reduction: rejected to avoid unexpected credential revocation.
• Ignore remediation entirely: rejected; would miss legitimate fixes.