Training & Certification

Defines Module O (LMS-lite): the course catalog, exam engine, the exam-gated certification that every government-side account must pass before it is activated to handle live tickets, and the ongoing learning, analytics, and audit that surround it.

ID scheme used in this doc. Functional requirements use FR-TRN-<nnn>; user stories use US-TRN-<nnn>; test cases use TC-TRN-<nnn>-<nn>. In addition, two stable, non-translated artifact codes are introduced here: CRS-<CAT>-<NN> for an individual course and EXAM-<CAT>-<NN> for an exam. Like FR/US/TC IDs, these are identical in EN/UR/SD so traceability is preserved. Categories: ONB onboarding · ROL role-based · DEP department-specific · REF refresher · CMP compliance · CO company-facing.

1. Purpose & Principles

Module O is a lightweight Learning Management System (LMS-lite). Its single most important job is to guarantee that no government-side account can handle a live ticket until that person has demonstrated competence through a proctored, randomized exam. This is the exam-gate (/specs/en/04-roles-permissions/ §14).

The module serves four goals:

1. Gate activation. Tie the handle-live-tickets capability to a passed certification, so training is enforced, not optional.
2. Baseline competence. Give every new staff member the same grounding in portal basics, ticket lifecycle, SLA, escalation, confidentiality, and compliance — regardless of which of the 40+ departments they join.
3. Ongoing competence. Keep staff current through annual refreshers and triggered re-certification on role change, so a transfer or promotion does not produce an untrained operator.
4. Auditable proof. Maintain an immutable record of who certified, when, on which exam version, in which language, and with what score — sufficient for RTI, internal audit, and CERT-PK coordination.

Design principles.

• Minimal viable LMS. SITP is a facilitation desk, not a training platform. Module O covers courses, exams, certification, and reporting — not full SCORM/xAPI, peer review, or live cohorts.
• Configurable, not hard-wired. Every default (passing score, attempts, expiry, required courses per role/dept) is overridable by Super Admin and (within scope) Department Admin.
• Content is versioned. A certification is always bound to a specific published version of a course and exam, so a later edit to content does not retroactively invalidate a previously-issued certificate.
• Multilingual by default. Every course and exam exists in EN, UR, and SD from first publish (see _context.md §2). A staff member takes the exam in their working language.
• Scenario over theory. Exams favour realistic SITP scenarios (a stalled ticket, a confidential attachment, a missing MoM) over rote recall.

2. Audience

Key rule. The exam-gate applies only to the government side (/specs/en/04-roles-permissions/ §14). Company representatives are gated by entity verification (see /specs/en/04-roles-permissions/ §4 and _context.md §5). Company-facing courses are offered to improve filing quality and reduce mis-routed tickets, but passing them does not affect account status.

3. Course Catalog

The catalog is organized into six categories. Each course is a short, focused unit (target 15–35 minutes of content). A learning path (§4) bundles courses into the right sequence per role.

Catalog legend: ID (stable, non-translated) · Title · Category · Primary audience · MoSCoW · Default required? · Linked exam (if any).

3.1 Onboarding courses

3.2 Role-based courses

3.3 Department-specific courses

Department-specific courses are authored per department from a shared template (the template course is CRS-DEP-TEMPLATE). They cover that department's domain categories, common ticket types, routing nuances, and any special handling. The Labour Department is the reference example; others clone the template.

3.4 Refresher courses

3.5 Compliance courses

3.6 Company-facing courses

These are short, public-facing modules surfaced in the company onboarding wizard and help center. They reduce filing errors and mis-routing.

Catalog totals: 18 taught courses across 19 catalog rows (4 onboarding + 5 role-based + 2 department-specific examples + 1 template + 1 refresher + 3 compliance + 3 company-facing = 19 rows, of which 18 are taught courses; CRS-DEP-TEMPLATE is an authoring template, not a taught course). See §14 Confirmation.

4. Learning Paths

A learning path is the ordered bundle of courses + the set of exams a given role must pass to be certified. Paths are configurable per role and per department by Super Admin (and, within scope, Department Admin). A path is what feeds the exam-gate in §6.

4.1 Learning path (visual)

Written description. When a government account is created and a role assigned, the system resolves that role's learning path (role + department combination). The staff member completes the onboarding courses, then role-based, then any department-specific courses if the department has opted in, then the compliance courses. They then sit the set of required exams, each proctored and randomized. If all are passed, a certificate is issued and the handle-live-tickets capability is switched on — the account is activated for live work. Failed exams can be retried up to a maximum-attempts cap; if exhausted, the account enters a Training Blocked state pending admin review or retraining. After a certificate's validity period (default N months), the staff member is routed to the annual refresher and a re-certification exam, which must pass before the certificate is renewed; the same gate re-applies.

5. Exams & Quizzes

Exams are the heart of the exam-gate. Each exam draws from a question bank, randomizes question order and answer order, supports multiple question types, and enforces anti-cheat controls.

5.1 Question banks

• Every exam is backed by a question bank scoped to its course(s). Banks are versioned with the exam (see §8).
• Each bank holds at least 2× the delivered question count so that no two attempts draw an identical set. Target: a bank of ≥ 40 items for a 20-question exam.
• Items are tagged by topic (e.g. sla, escalation, confidentiality, rti) and by difficulty (easy / medium / hard). The exam engine can stratify a draw (e.g. 10 easy + 7 medium + 3 hard).
• Items are flagged retired rather than deleted, so historical attempts remain reproducible.

5.2 Question types

5.3 Passing score, attempts, time

5.4 Anti-cheat & proctoring

Proctoring is tiered and configurable per exam (governed by data-sensitivity and exam criticality).

All proctoring flags are recorded with the attempt and visible to the author/admin in the attempt review screen and in audit logs. Webcam snapshots follow PII handling (/specs/en/11-security-compliance/) — restricted access, defined retention.

5.5 Randomization guarantees

• No two consecutive attempts by the same user draw the same question set (where bank size allows).
• Scenario stems may be parameterized (different ticket ID, department, urgency) so memorization is defeated.
• The exam engine records the exact question/option ordering used per attempt so any result is reproducible for appeal.

5.6 Exam schema

The structural fields of an exam record. Defaults are overridable per exam by Super Admin; within-scope overrides by Department Admin for department-specific exams.

5.7 Exam catalog

6. Exam Gate

The exam-gate is the binding between Module O and Module C (Org & RBAC). It is the single mechanism that makes training enforceable.

6.1 Gate rules

1. A government-side account may be created and may complete internal training, but the handle-live-tickets capability is withheld until the account's required exams are passed (/specs/en/04-roles-permissions/ §14).
2. While uncertified, the account is in a Training state: it can browse courses, sit exams, read (where permitted) KB and de-identified sample tickets, but cannot be assigned live tickets, comment on live tickets, resolve, or appear in auto-assignment/escalation routing.
3. On passing the last required exam, the system issues the certificate and flips the capability — the account is activated for live work and becomes eligible for ticket assignment.
4. If a certificate expires or is revoked (role change, failed re-cert, disciplinary), the capability is withdrawn and open live tickets assigned to that account are flagged for reassignment (mirroring the staff-deactivation-on-transfer behaviour in /specs/en/04-roles-permissions/ §11.1).
5. The gate applies to every government-side role that touches live tickets, including DG/Secretary oversight (they cannot act on escalated tickets until oversight-certified).

6.2 Configurable per role and per department

• The set of required exams for a given role is defined by its learning path (§4) and is configurable: Super Admin can add/remove a required exam platform-wide; Department Admin can opt their department into the department-specific exam (EXAM-DEPT-*) and (within policy) raise the passing threshold.
• Passing thresholds and attempt caps are configurable per exam, not globally fixed.
• A feature flag (FFG-TRN-GATE) lets Super Admin toggle the gate behaviour: enforced (default), advisory (warn but allow — for pilot/phase-1), off (disabled — only for break-glass migration). Default is enforced.

6.3 Grace period for existing staff

When the gate is first introduced (or a new required exam is added), existing staff who already hold live-ticket access are not deactivated overnight. They enter a grace period:

6.4 Certification gate flow (visual)

Written description. When a government account is created and a role is assigned, the system resolves the set of required exams for that role+department combination. The account enters the Training state with handle-live-tickets OFF. The staff member studies and sits each required exam (proctored and randomized). If all required exams are passed, the system issues the certificate(s) — recording who certified, when, on which exam version, in which language, and the score — and switches handle-live-tickets ON; the account becomes eligible for ticket assignment and escalation. On a failed attempt, the retake cooldown applies; once attempts are exhausted the account enters Training Blocked, which requires admin review or retraining before a reset. After activation, the certificate's validity is monitored: on expiry the staff member is routed to the refresher and re-cert exam (which re-enters the gate), and on a role change the old certificate is revoked and the new role's path is resolved — re-entering the gate at the top. At every transition the capability flag and ticket assignments are reconciled so no uncertified account retains live-ticket access.

7. Certification Lifecycle

A certification is a first-class record binding a person, an exam (at a specific version), a pass result, and a validity window. Its lifecycle is a small state machine.

7.1 Certification states

7.2 Lifecycle diagram

Written description. A certification begins Not started, moves to In progress on the first exam attempt, and becomes Certified once all required exams pass. A certified record transitions to Expiring soon inside the validity-warning window, then either renews to Certified on a successful re-certification, or lapses to Expired (capability withdrawn). At any active point the certification may be Revoked on role change or disciplinary action, sending the account back to resolve a new path. Exhausted attempts without a pass move the record to Blocked, lifted only by an admin reset after retraining. The handle-live-tickets capability follows the state machine: ON only while Certified or Expiring soon; OFF in every other state.

7.3 Issuance, expiry, re-certification, revocation, download

• Issued on pass. The moment the last required exam passes, a certificate record is created (person, exam ID + version, language, score, pass timestamp, issued-by, validity window) and a downloadable certificate is generated.
• Expiry. Each certificate has a validity_months (default 12, configurable per exam). Expiry is computed from issue date. The Expiring soon warning fires at a configurable lead time (default 30 days).
• Re-certification. Before expiry the staff member sits the refresher course + the re-certification exam (EXAM-REFRESHER, or the role's primary exams again, configurable). A pass extends validity by a fresh window; the prior certificate is superseded but retained in history.
• Revocation on role change. When a staff member's role changes (transfer, promotion — frequent in the Sindh government, see /specs/en/04-roles-permissions/ §11.1), the active certificate is revoked and the new role's path is resolved. If the new role requires fewer or equivalent exams, a fast-track may apply (configurable) — e.g. an Officer becoming a Dept Admin in the same department may keep the officer certification and only sit the admin increment.
• Revocation for cause. Super Admin / Department Admin (within scope) may revoke a certificate for disciplinary or compliance reasons; every revocation carries a reason code and is audit-logged.
• Downloadable certificate. Each issued certificate is downloadable as a trilingual PDF on SITP letterhead (Module L patterns) with a QR verification code so it can be independently checked. The certificate shows: holder name + designation, department, exam(s) passed + version, score band (not raw marks, configurable), issue date, expiry date, certificate ID, and the QR link.

8. Content Authoring & Governance

Module O ships with a small content-authoring workflow. Courses and exams are first-class, versioned, reviewable artifacts — not free text.

8.1 Author roles

Author/reviewer/publisher are scoped roles added on top of a person's base role (e.g. an S&ITD Facilitation Officer can additionally be a Course Author). They follow the same RBAC + override model (/specs/en/04-roles-permissions/ §6–§7).

8.2 Versioning

• Every course and exam carries a semantic version (MAJOR.MINOR.PATCH). Material content change = MAJOR; new questions/minor edits = MINOR; typo fixes = PATCH.
• A certification is always bound to the published version active at pass time. Editing a draft does not retroactively change a passed exam or an issued certificate.
• The current published version is what new attempts use. Old versions are retained (immutable) for reproducibility and appeal.
• A diff view between versions is available to reviewers.

8.3 Review & publish workflow

• Four-eyes rule. The reviewer and the author must be different accounts. Self-approval is blocked (Super Admin may override, audit-logged).
• Publish freezes the version (immutable) and makes it the active attempt target. Existing in-flight attempts finish on the prior version; new attempts use the new one.
• Retire removes a version from new attempts without deleting it; required for compliance history.
• Localization gate. A version cannot be published unless all three languages (EN/UR/SD) are present and marked translation-complete (see §9).

8.4 Content formats

Course content supports rich text (Markdown), embedded images, short videos (captioned, WCAG 2.1 AA), downloadable PDFs, and links to KB articles (Module J). Exam items support rich stems with attached snippets. All media is AV-scanned on upload (ClamAV, Module D) and stored encrypted.

9. Multilingual Courses & Exams

• Every course and exam is authored and published in EN (master), UR, and SD from first publish (_context.md §2, /specs/en/09-i18n-localization/).
• The EN version is the source of truth; UR and SD are faithful parallel translations. IDs (CRS-*, EXAM-*, FR-TRN-*, item-bank tags) are never translated.
• Each staff member takes courses and exams in their working language (account preference). The chosen language is recorded with every attempt for audit.
• Question banks are language-parity: an item exists in all three languages; the randomized draw is language-agnostic and rendered in the candidate's language.
• RTL rendering for UR/SD follows the platform convention (renderer-driven; no inline direction hacks). Arabic-script numerals, dates (Gregorian + Hijri), and currency follow the platform i18n rules.
• The localization gate in §8.3 blocks publication until all three languages are complete, preventing an EN-only exam from gating non-EN speakers.

10. Scenario-based Training (Sandbox)

Scenario-based training is what makes SITP certification credible: candidates practise on realistic, de-identified sample tickets in a sandbox that mirrors the live portal without touching real data.

• Sandbox environment. A read-only-to-live training space with seeded sample tickets, sample companies, and sample departments. Actions in the sandbox never affect production tickets or SLAs.
• Sample-ticket library. Authored by Course Authors, covering canonical situations: a mis-routed labour ticket; a stalled ticket needing a TRI meeting; a confidential attachment; an MoM with extractable action items; an RTI request with a statutory deadline; a VIP closure needing DG approval.
• Practical exam tasks (PRX type, §5.2) ask the candidate to do something: resolve a sandbox ticket with valid evidence; request a TRI meeting; upload and publish an MoM; flag a ticket confidential. A checklist (auto + reviewer) scores the task.
• AI in the loop. The sandbox exposes the same AI assistant (draft replies, summary, OCR, action-item extraction) so candidates learn when to trust and when to verify AI output — directly supporting CRS-ROL-04.
• Reset & retry. Sandbox state is resettable per candidate per attempt so scenarios are reproducible.

11. Analytics & Reporting

Module O exposes a focused analytics surface, surfaced in the role dashboards (Module I) and exportable for compliance reporting.

11.1 Core metrics

11.2 Dashboards & exports

• Super Admin sees platform-wide training analytics; Department Admin sees their department subtree; Authors/Reviewers see their assigned content.
• Exports (PDF/Excel/CSV) follow Module I conventions and require the analytics-export capability (step-up auth where appropriate, /specs/en/04-roles-permissions/ §12).
• Scheduled digests (e.g. weekly "newly certified this week", monthly "expiring next 30 days") feed the notification module.

12. Integration with RBAC

The exam-gate is realized as a direct integration with Module C (Org & RBAC). Certification status is a first-class input to authorization.

• Capability flag. The handle-live-tickets capability is computed from certification state: ON only when the account holds an active certificate covering its role's learning path. This is evaluated by the authorization engine alongside RBAC + ABAC (/specs/en/04-roles-permissions/ §6–§7) — an uncertified account is denied live-ticket capabilities even if its role template would otherwise grant them.
• Account activation hook. The account-lifecycle automation (/specs/en/04-roles-permissions/ §11) calls Module O on: account creation (resolve path), role change (revoke + re-resolve), transfer/deactivation (revoke). Conversely, Module O calls Module C on: certificate issued (activate), certificate expired/revoked (deactivate capability + flag reassignment).
• Ticket assignment & escalation filter. Auto-assignment and escalation routing exclude uncertified accounts, so a new joiner is never silently handed a live ticket before they are ready.
• Audit continuity. Certification events are written to the same immutable audit log as other access-relevant events (/specs/en/04-roles-permissions/ §11.5) and are visible to the Read-only Auditor.
• Feature flag. FFG-TRN-GATE controls gate enforcement level (§6.2). Changing the flag is itself an audited configuration event.

Written description. Module C notifies Module O whenever an account is created or a role changes, and Module O resolves the required learning path and withholds the handle-live-tickets capability. Once the user passes all required exams, Module O notifies Module C, which switches the capability ON and registers the account as eligible for ticket assignment and escalation. On expiry, role change, or revocation, Module O notifies Module C, which switches the capability OFF and flags any open tickets for reassignment. Module B never assigns or escalates to an uncertified account because the eligibility filter is computed from certification state in real time.

13. Records & Audit

Certification records are compliance artifacts and are treated with the same rigour as access logs.

• What is recorded (per attempt): candidate, exam ID + version, language, question/option ordering used, start/end timestamps, duration, score, pass/fail, proctoring flags, IP/device (where captured), attempt number, retake-cooldown compliance.
• What is recorded (per certificate): certificate ID, holder, designation, department, exam(s) + version, score band, issue timestamp, issued-by (system), validity window, chosen language, revocation status + reason (if any), QR verification token.
• Retention. Aligned with Sindh Archives rules and Module I/B retention (_context.md §6); expired/revoked certificates are never deleted — they are retained for the compliance retention period in a queryable archive.
• Immutability. Attempt records and issued certificates are append-only / tamper-evident (same audit log as access events).
• Access. The Read-only Auditor and Super Admin can query the full certification history platform-wide; Department Admin within their subtree; the holder can view their own. Step-up auth is required for bulk exports.
• Compliance reporting. One-click reports for: (a) "who is currently certified to handle live tickets in department X", (b) "certification history of person Y", (c) "gate-compliance % per department", suitable for RTI responses, internal audit, and CERT-PK coordination.
• Privacy. Scores are stored and displayed per privacy policy; the downloadable certificate shows a score band by default (configurable to show raw marks). Proctoring artifacts (webcam snapshots) follow PII handling with defined retention and restricted access (/specs/en/11-security-compliance/).

14. Functional Requirements

15. User Stories (selected)

US-TRN-001 — Get activated after passing required exams [Must]

As a newly onboarded Department Officer I want my account to switch on for live tickets automatically once I pass my required exams So that I can start resolving tickets without waiting for a manual activation step.

Acceptance Criteria (Gherkin)

Scenario: All required exams passed Given a Department Officer account exists in Training state with handle-live-tickets OFF When the officer passes the last required exam in their learning path Then a certificate is issued recording holder, exam version, language, score, and validity window And handle-live-tickets is set ON And the account becomes eligible for ticket assignment and escalation And a downloadable trilingual certificate with QR verification is generated

Scenario: Required exam failed Given an officer attempts a required exam When they score below the passing threshold Then the attempt is recorded with score and proctoring flags And the retake cooldown is applied And handle-live-tickets remains OFF

US-TRN-002 — Existing staff on grace period [Must]

As a Department Admin I want existing staff to keep working while they sit a newly-required exam So that the department's live ticket queue is not disrupted when the gate is introduced.

Acceptance Criteria (Gherkin)

Scenario Outline: Grace-period transitions Given an existing certified staff member is subject to a newly required exam When the grace window begins Then they see a persistent banner and reminders And they keep handle-live-tickets ON and remain eligible for assignment When the grace window elapses without a pass Then new tickets stop being auto-assigned to them When the hard cutoff elapses without a pass Then handle-live-tickets is set OFF and their open tickets are flagged for reassignment Examples: | grace_days | soft_extra | hard_extra | | 30 | 0 | 14 |

US-TRN-003 — Author publishes a multilingual exam [Must]

As an Exam Author I want to publish an exam only after EN/UR/SD are complete and a reviewer has approved So that no non-EN speaker is gated by a single-language exam and content quality is assured.

Acceptance Criteria (Gherkin)

Scenario: Publish with complete translations and reviewer approval Given an exam draft at version X has EN, UR, and SD marked complete And a different-account reviewer has approved it When the publisher publishes it Then version X becomes the active attempt target and is immutable And prior in-flight attempts continue on the prior version

Scenario: Block publish on missing language Given an exam draft is missing the SD translation When the publisher attempts to publish Then the publish is blocked with a localization-gate error

US-TRN-004 — Auditor queries certification history [Must]

As a Read-only Auditor I want to query who was certified when, in which language, and on which exam version So that I can support RTI, internal audit, and CERT-PK coordination.

Acceptance Criteria (Gherkin)

Scenario: Platform-wide certification query Given a Read-only Auditor is authenticated with step-up auth When they run the "certification history" report for department X Then they receive holder, designation, exam + version, score band, issue/expiry dates, language, and revocation status And the query itself is logged in the audit trail

16. Non-Functional Requirements (summary)

17. Configuration Defaults & Open Questions

Open questions.

1. Should company-facing courses (CRS-CO-*) carry an incentive (e.g. a "Trained Filer" badge that speeds verification) rather than remaining purely optional?
2. Should the annual refresher (CRS-REF-01) be a single consolidated exam or re-sit the original role exams?
3. For live remote proctoring of the Super Admin exam, which observer tool is the standard (Zoom / Meet / Teams), and what is the snapshot retention period?
4. Should the gate extend (advisory) to company representatives in regulated categories in a future phase?

Confirmation

• Courses (taught): 18 — 4 onboarding + 5 role-based + 2 department-specific examples + 1 refresher + 3 compliance + 3 company-facing. (Plus CRS-DEP-TEMPLATE, an authoring template, not counted as a taught course.)
• Exams: 9 catalogued (EXAM-ONB, EXAM-OFFICER, EXAM-FACILITATOR, EXAM-OVERSIGHT, EXAM-ADMIN, EXAM-COMPLIANCE, EXAM-DEPT-*, EXAM-REFRESHER, EXAM-CO).
• Sections: 17 (§1 Purpose & Principles through §17 Configuration & Open Questions).