Skill-Status Engine

The Skill-Status Engine (SSE) is the deterministic decision pipeline that transforms raw measurement evidence (θ rows from diagnostic sessions, CBM probes, and other evidence types) into interpretable statuses at three levels: per-sub-skill, per-domain, and per-macro-domain tile. Those statuses are the primary input to Student Profiles.

All SSE rules are versioned and published before being frozen. A published rule version is never edited; it is only superseded by a new version. This publish-then-freeze contract is what makes V-6 audit replay possible: a replay run re-executes the exact rule version that was active when the original decision was made.

The 5-layer pipeline

The SSE processes evidence through five sequential layers. Each layer reads only from its inputs and writes only to its designated outputs. There is no back-channel between layers.


Evidence in
    │
    ▼
[ADR] Assessment Decision Rules  (ADR-01..ADR-12)
    │  raw response → Final_Status_Code
    ▼
[FSC] Final_Status_Code          (12 codes)
    │
    ▼
[PAC/CIS] Pattern-Aware Confirmation  (PAC-01..PAC-13 + CIS-01..CIS-04)
    │  confirms or witholds the FSC based on cross-evidence patterns
    ▼
[SSR] Skill_Status_Rules_v2      (SSR-01..SSR-12)
    │  → 9-value SkillStatus + confidence + decision_strength
    ▼
[DDR] Domain_Decision_Rules_v2   (DDR-01..DDR-10)
    │  → 9-value DomainStatus
    ▼
[DSM] Domain_Status_To_Macro_Map (DSM-01..DSM-09)
    │  → the 6 macro-domain tile statuses
    ▼
Status out → Student Profiles

Layer 1: ADR (Assessment Decision Rules)

ADR-01 through ADR-12 classify each response by its behavioural characteristics. They are purely mechanical: given a response record, an ADR rule outputs a Final_Status_Code. No domain logic or pattern context is applied at this layer.

Layer 2: FSC (Final Status Code)

There are 12 Final Status Codes. They are internal identifiers, not exposed in any student-facing or parent-facing surface.

Layer 3: PAC/CIS (Pattern-Aware Confirmation)

PAC rules (PAC-01..PAC-13) check whether the FSC from layer 2 is consistent with the broader evidence pattern for that student and sub-skill. CIS rules (CIS-01..CIS-04) handle the cross-item consistency sub-checks. A PAC rule may confirm the FSC, withhold it pending more data, or trigger the do_not_decide_yet sentinel.

Layer 4: SSR (Skill Status Rules)

SSR-01 through SSR-12 synthesize the confirmed status into the 9-value SkillStatus enum, along with a confidence rating and decision_strength. The 9 SkillStatus values are:

SkillStatus	Meaning
`adequate`	Skill is on track
`monitor`	Skill is being watched but not yet a concern
`weak_isolated`	Weakness in this skill only
`monitor_gateway`	Gateway skill being monitored
`weak_gateway`	Gateway skill is weak
`weak_domain_related`	Weakness related to domain pattern
`broad_weakness_related`	Part of a broader cross-domain weakness
`cautionary_weakness_with_metadata`	Weakness noted with additional context
`contextual_review`	Requires contextual teacher review

Layer 5: DDR and DSM

DDR-01 through DDR-10 aggregate per-skill statuses within a domain into one of the 9 DomainStatus values (same vocabulary as SkillStatus). DSM-01 through DSM-09 then map domain statuses to the 6 macro-domain tile statuses (Meets, Approaching, Below, Severe, Not_Assessed).

The `do_not_decide_yet` sentinel

do_not_decide_yet is a hard halt. When the SSE emits this sentinel for a student × sub-skill combination, all downstream consumers must short-circuit. The student profile engine, the intervention bundle recommender, the teacher dashboard, and any reporting surface must treat this student as “more data needed”, not as any particular status.

There is no PATCH or override path to clear do_not_decide_yet at the API level. It clears automatically when sufficient evidence accumulates in a subsequent assessment window.

The sentinel is triggered by:

Insufficient comparable evidence (GSR-01: fewer than the minimum distinct items scored)
Tie-rule conflicts where two equally-weighted evidence sources point in opposite directions and no tiebreaker applies

When do_not_decide_yet is present the API returns nextRecommendedDataAction describing what data collection would resolve the halt.

Response-Behavior Metadata (RBM)

The SSE also collects Response-Behavior Metadata (RBM-00..RBM-11) alongside every scoring run. RBM flags capture administration conditions: distracted, tired, sick, noise, technical issue, or unusual assistance (6-key set per RBM-08). These flags are internal-only: they inform teacher review but never modify a score or status (scoreImpact: None is enforced on every RBM row). They are never shown to students or parents.

Gateway skills and the Arabic-accuracy carve-out

The SSE applies the gateway classification from the Skills Taxonomy at layer DDR. A weak_gateway or monitor_gateway SkillStatus escalates the surrounding domain’s DDR result.

Arabic-accuracy indicator sub-skills (shadda, tanween, madd, short-vowel marking, and related orthographic features) are explicitly excluded from gateway escalation paths (FR-SSE-10 enforces this carve-out). A weakness in one of these skills produces the ARABIC_ACCURACY_ONLY_MONITOR modifier on the student profile rather than a domain escalation.

Versioning and V-6 replay

Rules are published with a version number via a backoffice endpoint. A published version is immediately frozen. No edits are permitted. New rules arrive as a new version. All SSE rule tables (skill_status_rules, domain_decision_rules, domain_status_macro_map) carry a version + @@unique([key, version]) constraint so historical versions remain queryable.

Every SSE output row stamps the ruleVersion it used. The POST /api/engine/replay/:sessionId endpoint (backoffice-gated) re-runs a session’s frozen inputs against its original rule version to verify the output matches. If it does not, the audit log records a mismatch; this is the V-6 integrity check.

How SSE connects to Student Profiles

The SSE writes per-sub-skill and per-domain status rows. The Student Profile module reads those rows and:

Applies the anti-overlap rules (AO-01..AO-04) to select exactly one primary profile
Attaches modifier profiles (including ARABIC_ACCURACY_ONLY_MONITOR from the carve-out)
Derives sub-flags (AR_MADD_FLAG, VOCAB_ALERT, etc.)
Selects the SPOT narrative template
Returns the profile for teacher review (pending_teacher_review initial status, per V-12)

Key API surfaces

The SSE does not expose its intermediate layers directly. Consumers interact with it through the bundle recommendation and profile endpoints, which call the SSE internally. Backoffice endpoints for rule management and replay are gated behind RUN_BACKOFFICE.

For the authoritative endpoint list see the API Reference (skill-status-engine tag).

Skills Taxonomy: defines gateway flags and Arabic-accuracy indicators the SSE uses
Student Profiles: the direct consumer of SSE status output
Intervention Bundles: bundle selection depends on profile, which depends on SSE
Progress Monitoring: GSR safety rules (GSR-01..GSR-05) apply to SSE decisions
The Decision Engine: conceptual overview of the full pipeline
Glossary: SkillStatus (9), DomainStatus (9), do_not_decide_yet, gateway skill, RBM