A Manual Completion Is Not an Earned Reward

A Manual Completion Is Not an Earned Reward

In the academy operations review behind this case, an admin shortcut could mark learning progress complete without issuing reward points. That observation did not establish that rewards were mispaid. It exposed three operational questions: who could make the correction, how mistakes could be reversed and which downstream systems should react.

An LMS progress override should repair the intended record, not silently manufacture assessment evidence or reward entitlement.

Four records replace one misleading percentage

The xAPI result model distinguishes completion from success. (github.com) The proposed academy model extends that separation into four linked records.

• Progress records the learner’s position and whether completion came from activity or an administrator.
• Assessment evidence preserves attempts, scores and pass decisions against a defined assessment version.
• Completion eligibility records whether course or certificate requirements were met under a specific rule version.
• The incentive record separates training reward entitlement from settlement status and the amount actually issued.

A valid model case is progress=completed_by_admin, assessment=unattempted and points_earned=0, with a recorded reason. Certificate eligibility remains a separate policy decision.

Administrative authority belongs to the transition

OWASP recommends least privilege and permission checks on every request. (cheatsheetseries.owasp.org) Applied to LMS admin permissions, progress correction, certificate exceptions and reward adjustments should be separate capabilities enforced server-side. Access to the learner dashboard should not imply authority over all three.

OWASP’s logging guidance covers event identity, timing, action and outcome. (cheatsheetseries.owasp.org) For this learner progress audit trail, each exceptional change should also capture its scope, before-and-after values, reason code, evidence reference and authorization. Automated jobs need identifiable service actors too.

Reversal corrects the present without deleting the past

xAPI provides a useful precedent by voiding statements without destroying them. (github.com) An academy can follow that principle with a compensating adjustment referencing the mistaken override, while preserving assessment attempts and rebuilding the current progress view.

A progress reset must not erase an earned reward. Any legitimate reward reversal needs its own authorized decision and linked ledger entry. Replaying learning events must not settle the same entitlement again.

Reward rules consume evidence rather than interface values

For learn and earn rewards, the reward service should evaluate authoritative evidence against a versioned campaign rule. A displayed completion percentage is not that evidence. Certificate eligibility may be an input, but should not automatically establish entitlement.

PostgreSQL supports uniqueness across a combination of columns. (postgresql.org) One implementation could enforce a non-null key combining learner, campaign and reward occurrence. Retries should return the existing entitlement. External settlement should reuse a stable idempotency key and reconcile uncertain outcomes before another issuance attempt.

Boundary tests expose unintended side effects

• Manual completion without an assessment leaves mastery unproven and rewards unissued.
• A certificate exception changes certificate eligibility without granting points unless the reward policy explicitly allows it.
• Reversing an override preserves earlier attempts and the correction history.
• Resetting progress leaves existing earned entitlements and settlement records intact.
• Concurrent requests and replayed events produce one entitlement and no duplicate settlement.
• Unauthorized changes fail without mutation and leave an audit event.

The minimal model makes consequences explicit

A minimal implementation needs four linked domain records, an append-only adjustment history and a transactional outbox for settlement messages. Every transition names its permitted actor, required evidence and downstream consumers. Support should inspect server-side eligibility and settlement records rather than infer entitlement from an error message.

For App-Learning, the technology-partner contribution is making these boundaries explicit across embedded education and product systems. Another dashboard button is not the answer. Operators need to correct a learning record without rewriting what the learner demonstrated or what the business owes.