Canonical assessment-form catalog and program baseline

DEC-0073 - Canonical assessment-form catalog and program baseline

Context

Exercise-bank docs for SAT/TOEIC/Communication still have placeholder uncertainty at taxonomy depth, creating weak alignment between content routing and core engines (goal comparison, recommendation, metrics).

Decision

Canonical form contract:

• every attempt/result must map to one stable assessment_form_id.
• each form record includes:
  • program_id,
  • skill_id,
  • scoring_family (objective | subjective_ai | hybrid),
  • score_profile_id,
  • timing_family (untimed | timed | adaptive).

Program baseline profiles:

• SAT baseline forms (4):
  • verbal mixed objective,
  • verbal one-type objective,
  • math mixed objective,
  • math one-type objective.
• TOEIC baseline forms (4):
  • reading objective parted,
  • listening objective parted,
  • writing subjective-ai task,
  • speaking subjective-ai part.
• Communication baseline forms (4):
  • speaking scenario ai,
  • writing scenario ai,
  • microdrill objective,
  • integrated mixed.

Cross-module lock:

• Goal onboarding source for form/skill options is canonical form catalog.
• Recommendation fallback “same assessment form” is keyed by assessment_form_id.
• Metrics comparability uses assessment_form_id + score_profile_id.

Scope guardrail:

• detailed leaf filters/taxonomy remain content-profile layer and can evolve without changing core engine contracts.

Decision Value

• Removes ambiguity while keeping docs lean.
• Enables stable personalization logic even when content taxonomy expands.
• Keeps system scalable by separating engine contracts from leaf-content churn.

Rationale

A stable form ID layer is the minimal contract needed for coherent behavior across Home, Practice, Goal, and Metrics without overengineering.

Implications

• Product/UX impact:
  • bank pages become implementation-ready at baseline level.
  • users get more consistent guidance and comparison behavior.
• Data/logic impact:
  • core services must resolve each attempt to canonical assessment_form_id.
• Operational impact:
  • content teams can iterate leaf taxonomies independently.

Alternatives considered

• Option A: Keep program docs as placeholders and let each module infer form taxonomy separately.
• Option B: Encode all leaf taxonomy directly into core engine logic.

Open follow-ups

• No open blocker for baseline lock.