Program-specific goal scale and assessment-form-aware comparison

DEC-0071 - Program-specific goal scale and assessment-form-aware comparison

Context

Programs in DOL English differ by exercise families and assessment formats. A single target-score input/comparison model creates confusing UX and weak personalization quality.

Decision

Goal profile baseline:

• goal is still optional globally.
• if learner sets goal, goal must be stored with:
  • goal_program_id,
  • goal_assessment_form,
  • goal_scale_profile_id,
  • goal_target_value.
• onboarding input options are rendered from program + assessment-form profile, not one global score field.

Comparison baseline:

• each submitted result must carry:
  • attempt_score_profile_id,
  • attempt_score_value.
• comparison mode:
  • direct: goal and attempt share same scale profile,
  • normalized: allowed only when profile map explicitly defines safe normalization,
  • not_comparable: no safe mapping.
• if not_comparable:
  • do not show distance-to-goal number,
  • show trend/progress only with short explanatory copy.

Simplicity and scale guardrail:

• no per-item hardcoded comparison rule in UX.
• use profile-driven contracts so new programs/forms are added by configuration.

Decision Value

• Keeps goal experience accurate across programs without overcomplicated UI logic.
• Prevents misleading target gap numbers.
• Preserves simple user-facing behavior while remaining scalable for more programs and exercise formats.

Rationale

The product objective is “full but lean”. Program/form-aware score contracts preserve clarity and trust, while avoiding brittle custom logic for each individual exercise type.

Implications

• Product/UX impact:
  • goal setup becomes context-aware after program selection,
  • goal-gap UI appears only when comparison is valid.
• Data/logic impact:
  • result pipeline and metrics layer require explicit score profile metadata.
• Operational impact:
  • teams can launch new exercise forms without rewriting core comparison logic.

Alternatives considered

• Option A: One shared percentage model for all programs/forms.
• Option B: Per-exercise bespoke goal logic in frontend.

Open follow-ups

• No open blocker for baseline lock.