Detailed Project Report for Exam Management System

1. OverviewPDF p.5

The Craftsmen Training Scheme examination is the formal assessment and certification stage that follows State-led admission and ITI training. For PM-SETU, this DPR does not propose a separate examination portal. The operating design is to integrate PM-SETU with the existing Skill India Digital Hub (SIDH) examination ecosystem and reuse the existing SIDH examination flows for candidate registration, eligibility, centre / shift visibility, practical marks, result publication and digital certification. States continue to manage admission and practical execution, NIMI continues to govern the question bank, the CBT examination agency continues to conduct the theory examination, and DGT continues to control the national examination calendar and result rules. PM-SETU introduces the scheme-specific configuration, identifiers, data contracts and downstream data exchange needed to make these existing flows visible and measurable within the PM-SETU programme without creating a second source of truth. SIDH will remain the authoritative examination-facing platform and the persistent candidate, result and certification record. A PM-SETU learner will therefore not receive a new examination identity solely for this module. The primary person-level key will be the existing SIDH learner / candidate identifier used by the examination process, while PM-SETU participation will be distinguished through a scheme-participation mapping carried with the learner record. At minimum, that mapping will associate the SIDH learner / candidate ID with PM-SETU scheme participation, ITI code, Hub-and-Spoke cluster / institution context, trade or course, batch and examination cycle. The exact SIDH field name used for the PM-SETU scheme marker is to be confirmed in the production SIDH data contract; the design requirement is a stable scheme- level attribute or mapping, not a parallel student ID. Validated examination events for this PM- SETU cohort will then be published through the common PM-SETU integration / canonical data layer for consumption by LMS, Monitoring and Analytics according to their system boundaries.

1.1. ScopePDF p.5

The scope of this DPR is the PM-SETU integration and configuration required within and around the existing SIDH examination process, beginning with identification of the PM-SETU candidate cohort and ending with publication of result and digital certification. The SIDH examination flow will continue to configure Main and Supplementary cycles, apply eligibility rules, establish the candidate universe, coordinate question-bank and paper-generation hand-offs, manage centre / shift and practical-examination workflows, receive CBT and practical / project-OJT marks, apply approved result and grace-mark rules, and publish the final outcome. PM-SETU-specific requirements are to ensure that each relevant transaction can be isolated using the SIDH learner / candidate ID plus the PM-SETU participation context and that validated events can be exchanged with the wider PM-SETU digital ecosystem. Admission remains a State responsibility and is outside the transactional scope of this DPR. SIDH will continue to consume and persist the verified candidate and admission context after State admission, and PM-SETU will reuse that identity rather than recreate it. Training delivery remains within LMS / ITI operations; only attendance, Formative Assessment (FA), project work and OJT information required by the existing examination flow is exchanged with SIDH. Practical examination execution remains State-led. The integration boundary is therefore explicit: SIDH is authoritative for examination registration, examination status, marks/result and certification; LMS is authoritative for the detailed learning-operational record; Monitoring consumes approved programme/KPI evidence; and Analytics presents reconciled cross-system views without becoming a source of first entry.

1.2. Key AssumptionsPDF p.5

• •Candidate identity and admission status will be available on SIDH after State-level admission, Aadhaar e-KYC and applicable APAAR linkage. The existing SIDH learner / candidate identifier will be the primary person-level key. In addition, SIDH shall carry a dedicated PM-SETU identifier / scheme tag against each PM-SETU learner record so that PM-SETU candidates can be uniquely identified and filtered throughout the examination lifecycle without creating a separate parallel learner identity.
• •The PM-SETU identifier / scheme tag shall be persistently linked to the SIDH learner / candidate ID and carried with the relevant ITI, Hub-and-Spoke cluster, trade / course, batch and examination-cycle context. The identifier must be available through the approved SIDH interface / API and included in examination data exchanges so that candidate eligibility, fee

status, centre mapping, examination events, results and certification can be reliably reconciled and routed to the PM-SETU LMS, Monitoring and Analytics platforms.

• •Examination eligibility will continue to follow the approved SIDH / CTS examination process and the configured thresholds applicable to the cycle, including the current discussion of at least 80% attendance and 60% FA. Thresholds remain configurable so that policy change does not require code change.
• •DGT will continue to define the national examination schedule and result rules in the existing examination ecosystem; State authorities will continue to appoint practical examiners and govern practical execution within the approved national schedule. PM-SETU will consume these statuses rather than create parallel approval flows.
• •NIMI will continue to own question-bank development for applicable trades and the examination agency will continue to apply approved generation rules. PM-SETU requires the relevant bank / paper-generation references and examination events to remain traceable to the SIDH candidate and PM-SETU participation context.
• •Validated PM-SETU examination events will be exposed through the common PM-SETU integration gateway / canonical data model. LMS will consume examination and credential references needed for the learner journey; Monitoring will consume approved KPI / milestone evidence; Analytics will consume reconciled appearance, result, pass-rate and certification data. None of these consumers will overwrite the authoritative SIDH examination record. The table below summarises the principal stakeholders and their role in the examination ecosystem.

2. Business RequirementsPDF p.7

The PM-SETU examination requirement is principally an integration and programme- identification requirement on top of the existing SIDH examination ecosystem, not a greenfield replacement of it. The current SIDH / CTS flows already bring together candidate identity, admission context, attendance and FA eligibility, examination cycle, centre and shift, practical and CBT marks, result and certification. PM-SETU must make those same flows scheme-aware so that a PM-SETU learner can be identified consistently from registration through certification and the resulting data can be consumed by the other PM-SETU platforms without duplicate entry or conflicting records. Accordingly, the user journeys in Sections 2.1 to 2.5 describe the existing SIDH-linked examination flows, with the PM-SETU additions shown as identification, filtering, integration and analytics requirements. The cohort is resolved using the SIDH learner / candidate ID together with the PM-SETU participation mapping and programme context (ITI, cluster, trade/course, batch and cycle). For every material examination event, the interface must preserve source system, source identifier, timestamp, validation status and lineage. Validated PM-SETU events are then passed through the common Integration Gateway / canonical PM-SETU data layer: LMS receives examination/result/credential references required to present the learner journey; Monitoring receives approved KPI / evidence fields; and Analytics receives reconciled examination appearance, result, pass-rate and certification measures for role- and entity- scoped dashboards. The system capabilities are organised around nine functional pillars. The matrix below provides a concise view before the detailed requirements in Section 3.

User Journeys

2.1. Candidate / trainee user journeyPDF p.9

• •This is the existing SIDH candidate / trainee examination journey reused for PM-SETU. PM- SETU does not create a second learner or exam account: the SIDH learner / candidate ID remains the person-level key, while a PM-SETU participation mapping identifies the scheme cohort and links the learner to the relevant ITI, cluster, trade/course, batch and examination cycle.

User journeyPDF p.9

Tap to enlarge

• •Registration and identity:

The candidate continues to use the SIDH identity created after State admission, Aadhaar e-KYC and applicable APAAR linkage. The examination interface resolves the SIDH learner / candidate ID and verifies the PM-SETU participation context before the record is included in a PM-SETU cycle.

• •Eligibility: The existing SIDH-linked attendance and FA checks are applied under the configured examination rule. The eligibility decision retains the learner ID, scheme context, source and rule version for audit and downstream reporting.
• •Examination allocation:

Eligible PM-SETU candidates receive the applicable Main or Supplementary cycle, centre, shift and schedule through the existing SIDH examination flow after the mapping has been approved.

• •Examination and outcome: CBT, practical and other required components follow the existing SIDH / State / agency operating flow. The final result, digitally signed marksheet and QR-enabled certificate remain available through SIDH.
• •PM-SETU data use: Validated registration, appearance, result and certification events are published through the common PM-SETU integration layer. LMS consumes the examination / credential reference; Monitoring consumes approved KPI evidence; Analytics consumes reconciled examination and outcome measures.

Footnote: This user journey reflects the existing DGT examination process on SIDH and has been captured based on discussions with the respective DGT/SIDH/examination teams. PM-SETU reuses the existing flow and adds programme identification and governed data integration; it does not create a parallel examination workflow.

User journeyPDF p.9

Tap to enlarge

2.2. ITI / examiner user journeyPDF p.9

• •This is the existing ITI / examiner practical- examination flow connected to SIDH, with PM- SETU cohort identification added to each mapped batch. The ITI and examiner do not create a separate PM-SETU candidate record; the same SIDH learner / candidate ID and PM-SETU participation context are used throughout preparation, marks entry and approval.
• •Readiness: The ITI receives the cycle schedule through the existing process and ensures attendance and FA records required for SIDH eligibility determination are available.
• •Candidate list: The practical workspace shows

only candidates already resolved in SIDH and mapped to the PM-SETU cohort, institution, trade/course, batch and cycle. An examiner cannot create an unregistered candidate.

• •Practical conduct and marks: The State-appointed examiner conducts the practical examination at the approved venue and uploads marks through the existing SIDH-linked workflow; the marks remain attributable to learner ID, examiner, trade, institution and cycle.
• •Nodal approval: The mapped batch is reviewed through the existing approval route. Returned records are corrected without reopening unaffected candidates.
• •PM-SETU data use: Approved practical / component events retain source and lineage and are made available to the PM-SETU integration layer for result reconciliation, Monitoring evidence and Analytics.

Footnote: This user journey reflects the existing DGT examination process on SIDH and has been captured based on discussions with the respective DGT/SIDH/examination teams. PM-SETU reuses the existing flow and adds programme identification and governed data integration; it does not create a parallel examination workflow.

2.3. DGT examination control user journeyPDF p.10

• •This is the existing DGT examination-control flow operating over SIDH. For PM-SETU, the principal addition is the ability to filter and govern the PM- SETU candidate universe using the SIDH learner / candidate ID plus scheme, institution/cluster, trade/course and batch context, while preserving the same national cycle and result-control process.

User journeyPDF p.10

Tap to enlarge

• •Cycle configuration: Configure the Main or Supplementary cycle in the existing examination- control process and mark the PM-SETU applicability / cohort criteria for that cycle.
• •Candidate freeze: Confirm the PM-SETU eligible universe after attendance and FA checks; the frozen set must reconcile to SIDH candidate IDs and the PM-SETU participation mapping.
• •Operational monitoring: Track centre / shift

readiness, practical progress, CBT completion and marks return through the existing SIDH-linked control view, with PM-SETU filters rather than a separate dashboard database.

• •Result control: Reconcile component marks, apply the approved result and grace-mark rule and hold incomplete cases as exceptions within the existing result workflow.
• •Publication and data exchange: Publish the authoritative result / certificate status on SIDH and emit validated PM-SETU result events to the common integration/KPI layer for LMS, Monitoring and Analytics.

Footnote: This user journey reflects the existing DGT examination process on SIDH and has been captured based on discussions with the respective DGT/SIDH/examination teams. PM-SETU reuses the existing flow and adds programme identification and governed data integration; it does not create a parallel examination workflow.

2.4. NIMI / examination agency user journeyPDF p.11

• •This is the existing question-bank and CBT examination-agency flow integrated with the SIDH examination cycle. NIMI remains the owner of approved question content and the examination agency remains responsible for paper generation and CBT execution; PM-SETU adds cohort and cycle traceability, not a parallel question-bank or CBT engine.

User journeyPDF p.11

Tap to enlarge

• •Authoring and quality control: NIMI continues to

empanel experts, author, vet and translate questions under the existing governance route.

• •Handover: The approved bank is shared with the examination agency in the agreed structured format and linked to the applicable SIDH cycle / trade and PM-SETU cohort where relevant.
• •Paper generation: The agency engine applies the approved selection and randomisation rules for the relevant shift; the generated paper remains traceable to the bank and rule version without exposing restricted content to PM-SETU analytics consumers.
• •CBT conduct and marks return: The agency conducts CBT and returns marks against the same SIDH candidate identifiers used in the frozen candidate universe.
• •PM-SETU data use: Only validated, non-restricted examination events and outcomes required for programme monitoring are published to the PM-SETU canonical data/KPI layer; question content itself remains within the restricted examination boundary.

Footnote: This user journey reflects the existing DGT examination process on SIDH and has been captured based on discussions with the respective DGT/SIDH/examination teams. PM-SETU reuses the existing flow and adds programme identification and governed data integration; it does not create a parallel examination workflow.

2.5. State Directorate user journeyPDF p.11

• •This is the existing State Directorate / SIDH examination-arrangement flow. PM-SETU does not create a separate State approval route; it requires the current centre, practical and approval transactions to carry the common SIDH candidate and PM-SETU programme context so that State execution can be reconciled with national monitoring.

User journeyPDF p.11

Tap to enlarge

• •Centre review: Review the examination-agency proposal for centre capacity, travel distance and State restrictions within the existing approval flow, with PM-SETU cohort filters where required.
• •Approval / return: Approve or return the mapping with observations; a returned proposal must not become visible as final candidate allotment on SIDH.
• •Practical execution: Appoint examiners and venues within the approved schedule and retain the SIDH cycle, learner/batch and PM-SETU institution/cluster context.
• •Monitoring: Track practical completion and unresolved exceptions through the existing

operational workflow; only validated status is passed into PM-SETU monitoring and analytics.

• •Audit and data exchange: Every approval, return and material mapping change remains attributable to the State user and cycle, and approved PM-SETU events are published through the common integration layer.

Footnote: This user journey reflects the existing DGT examination process on SIDH and has been captured based on discussions with the respective DGT/SIDH/examination teams. PM-SETU reuses the existing flow and adds programme identification and governed data integration; it does not create a parallel examination workflow.

3. Functional System RequirementsPDF p.12

This section translates the existing SIDH-linked operating model in Section 2 into PM-SETU requirements. Unless explicitly stated otherwise, each requirement is a configuration, extension or governed integration requirement on the existing SIDH examination ecosystem rather than a requirement for a standalone PM-SETU examination portal. Every pillar must preserve the SIDH learner / candidate ID and the PM-SETU participation context, retain source and rule lineage, and publish only validated PM-SETU events required by downstream LMS, Monitoring and Analytics. Each pillar is specified in the same form: business purpose, Functional Capabilities, Acceptance Criteria, Validation Rules and Exception Management.

3.1. Pillar 1: Exam cycle and calendar managementPDF p.12

The system shall establish the examination cycle as the controlling configuration for every downstream examination transaction. It shall support the two annual CTS cycles discussed - Main and Supplementary - and shall hold the dates, course / year applicability, fee windows, candidate-freeze milestones, theory and practical schedules and result-processing period against one versioned cycle record.

Functional Capabilities:

Cycle configuration: Authorised examination-control users create a Main or Supplementary cycle and define its academic period, status and applicable course durations.

• •Configure separate milestones for candidate eligibility, CBT fee payment, candidate freeze, centre mapping, theory examination, practical examination, marks cut-off, result processing and certification.
• •Support six-month, one-year and two-year programmes and distinguish first-year / second- year applicability where required. Publication and change control: Publish the approved schedule to authorised State, ITI, agency and candidate views.
• •Record every material schedule change as a controlled revision with reason, approver and effective timestamp.
• •Prevent a change from silently altering a completed activity or historical result. Main / Supplementary relationship: Link a Supplementary cycle to the relevant Main cycle so that eligible failed or absent candidates can be identified without re-creating the original result history.
• •Allow fee, timetable or centre arrangements to differ between Main and Supplementary cycles while retaining the parent examination reference.

Acceptance Criteria

• •A cycle cannot be opened without its type, academic period, applicable courses and mandatory milestone dates.
• •The published schedule is identical across authorised user views for the same cycle version.
• •A Supplementary cycle can identify the originating Main result for every routed candidate.

Validation Rules

• •Only authorised examination-control roles may create, publish, revise or close an examination cycle.
• •A completed milestone cannot be removed; a correction creates a revised schedule entry with history.
• •A candidate cannot be mapped to a cycle outside the candidate course / year applicability.

Exception Management

3.2. Pillar 2: Candidate eligibility and exam registrationPDF p.13

Candidate eligibility and examination registration shall be performed through the existing SIDH examination process using the verified SIDH learner / candidate record and the configured eligibility policy. PM-SETU will not recreate State admission or learner identity. The capability must resolve the PM-SETU participation mapping, consume the required course/year, attendance and FA inputs and produce a traceable eligibility decision before the candidate enters the PM-SETU examination cohort.

Functional Capabilities:

Candidate intake and identity: Consume the existing SIDH learner / candidate identifier and the PM-SETU participation mapping together with admission / enrolment context, ITI, cluster, trade/course, course duration, year, batch and cycle through the approved SIDH interface. Do not generate a parallel PM-SETU examination learner ID.

• •Retain the source identifier and last successful refresh on every externally supplied candidate attribute.
• •Use the verified candidate record already established through Aadhaar e-KYC and applicable APAAR linkage. Eligibility rules: Evaluate attendance and FA against the configured thresholds for the cycle, including the currently discussed 80% attendance and 60% FA thresholds.
• •Store actual value, threshold, source, evaluation time and rule version for every eligibility decision.
• •Allow authorised policy administrators to configure future approved thresholds without changing historical decisions. Registration and candidate freeze: Open exam registration / fee action only for candidates satisfying the configured eligibility conditions and cycle applicability.
• •Create a frozen candidate universe for downstream centre / shift and examination-agency processing.
• •Support Main and Supplementary routing, including failed and absent status where applicable.

Acceptance Criteria

• •Every eligible / not-eligible decision can be traced to the candidate, attendance value, FA value, cycle and rule version.
• •An ineligible candidate cannot be included in the frozen examination universe without an authorised exception process.
• •The frozen candidate count and downstream agency count reconcile to the same cycle snapshot.

Validation Rules

• •A candidate identifier must resolve to one valid SIDH record before registration.
• •Eligibility cannot be inferred where attendance or FA is missing; the candidate is shown as pending / incomplete.
• •A candidate cannot be duplicated in the same cycle, centre and shift allocation.

Exception Management

3.3. Pillar 3: Question bank and paper generationPDF p.14

Question-bank and paper-generation requirements will use the existing NIMI-to-examination- agency operating flow linked to the SIDH examination cycle. NIMI remains authoritative for the approved bank and the agency generation engine applies the configured CBT selection rules. PM-SETU requires consistent cycle, trade and cohort references for traceability and analytics, but does not replicate restricted question content in the PM-SETU data layer.

Functional Capabilities:

Question-bank governance: Register question-bank versions by trade, chapter / topic, language, status and owning authority.

• •Capture authoring / expert provenance, vetting stage and translation status without exposing restricted question content to unauthorised users.
• •Accept the approved bank from NIMI in the agreed structured exchange format and validate completeness before release. Generation rules: Configure the selection blueprint, chapter / topic distribution, number of questions, language, randomisation and other approved generation parameters by examination cycle.
• •Generate the CBT paper from the approved bank through the designated agency engine and retain the rule / bank version used.
• •Prevent use of a draft, unvetted or superseded bank in a live paper generation event. Practical-paper readiness: Support trade-wise applicability for centrally generated practical papers.
• •Allow the programme to expand centralised practical-paper coverage from the current limited set of trades without redesigning the process.
• •Retain State-generated arrangements for trades not yet brought under the centralised process.

Acceptance Criteria

• •Every generated paper is traceable to the approved bank version and generation rule version.
• •No user outside the prescribed role can browse live restricted question content or generated papers.
• •The system can identify which trades use centralised practical papers for a given cycle.

Validation Rules

• •Only Approved question-bank versions may be released to the generation engine.
• •A generation request must reference one examination cycle, trade, paper type and rule version.
• •A generated paper cannot be edited manually after sealing; correction requires a new controlled generation event.

Exception Management

3.4. Pillar 4: Centre, shift and CBT managementPDF p.15

Centre, shift and CBT management will continue through the existing SIDH-linked examination flow from the frozen candidate universe to centre / shift approval and marks return. The examination agency proposes the operational mapping and the State Directorate approves the final arrangement. PM-SETU adds scheme-aware candidate filtering and common identifiers so allotment, appearance and marks can be reconciled with the wider PM-SETU learner record.

Functional Capabilities:

Centre master and proposal: Maintain centre identity, institution type, capacity, location, available shifts and applicable State restrictions for each cycle.

• •Allow the examination agency to propose candidate-to-centre and shift mapping from the frozen candidate universe.
• •Calculate or receive the travel-distance check required by the approved allocation rule, including the approximately 25 km parameter discussed for the current process. State approval: Present centre and shift proposals to the relevant State Directorate for approval or return with observations.
• •Prevent a returned or unapproved mapping from becoming a final candidate allotment.
• •Record the approving State user, timestamp and mapping version. CBT execution and data exchange: Provide the approved candidate database to the examination agency through the governed API interface.
• •Record examination attendance / conduct status where returned by the agency.
• •Receive candidate CBT marks through APIs and reconcile them to the candidate, examination cycle, trade and shift before result processing.

Acceptance Criteria

• •Every candidate allotment references an approved centre, shift and State approval record.
• •Candidate data sent to the agency reconciles to the frozen cycle snapshot.
• •CBT marks returned by the agency are matched to exactly one candidate and examination event before acceptance.

Validation Rules

• •A centre cannot exceed its approved capacity for a shift.
• •A State-restricted centre type cannot be allotted where the State configuration prohibits it.
• •An unapproved mapping cannot be published to candidates.
• •An incoming CBT result must reference the valid candidate and cycle identifiers supplied to the agency.

Exception Management

3.5. Pillar 5: Practical examination managementPDF p.16

Practical examination management will continue through the existing State-led, SIDH-linked workflow while maintaining one national candidate, schedule and marks record. PM-SETU does not digitise the physical trade task or create a separate marks application; it requires examiner, venue, batch, marks and Nodal approval events to remain linked to the SIDH learner / candidate ID and PM-SETU institution/cluster, trade/course, batch and cycle context.

Functional Capabilities:

Examiner and venue mapping: Record the State-appointed examiner, approved venue, trade, batch and practical date against the examination cycle.

• •Allow the same ITI or an approved nearby ITI to be used as the practical venue subject to the State / DGT rule.
• •Prevent an examiner from entering marks for a candidate outside the assigned batch or trade. Practical conduct and marks: Present the approved practical paper / task reference where centralised practical papers apply.
• •Allow the examiner to enter practical and viva components in the configured marking pattern and save work before final submission where permitted.
• •Capture the submission timestamp, examiner identity and candidate batch; support same- day upload as the operating expectation. Nodal approval: Route the submitted mapped batch to the Nodal authority for approval or selective return.
• •Lock approved marks against ordinary edit and require a controlled correction event for any later change.
• •Expose completion / pending status to examination control for result readiness.

Acceptance Criteria

• •Every practical mark identifies the candidate, trade, cycle, examiner, venue and approval status.
• •A Nodal authority can return only the affected candidate record without reopening an approved unaffected batch.
• •Result processing cannot treat a missing practical mark as zero unless the approved rule explicitly defines that treatment.

Validation Rules

• •Only the assigned examiner may submit marks for the mapped batch.
• •Approved marks cannot be overwritten in place.
• •A candidate cannot have two simultaneously active practical marks for the same exam event.

Exception Management

3.6. Pillar 6: Project work / OJT and component marksPDF p.17

Project work and OJT components that contribute to examination outcomes shall be linked to the same SIDH candidate and PM-SETU programme context used by the examination cycle. Where these components originate in LMS, ITI or industry workflows, the source remains authoritative and the examination process consumes the validated value / reference required for scoring; duplicate re-entry into a separate PM-SETU examination store is not the target design.

Functional Capabilities:

Component configuration: Define the project / OJT components applicable to the course and examination cycle, including maximum marks, contributor type and grading rule.

• •Support more than one authorised contributor to the same component, including industry and examiner / viva input where prescribed. Marks capture: Allow the ITI to submit the authorised component marks with contributor / source reference and evidence status.
• •Retain the industry-origin component separately from examiner-entered marks rather than merging them at data-entry time.
• •Calculate the grade only after the required components are complete and approved. Project credential: Where the approved scheme requires a separate project-work certificate, retain the result and issue status independently from the main trade certificate while linking both to the same learner record.

Acceptance Criteria

• •Every project / OJT mark is attributable to the candidate, component, contributor / source and cycle.
• •A grade is not produced while a mandatory component is missing.
• •A separate project-work certificate, where configured, can be traced back to the component marks that supported it.

Validation Rules

• •Only the role configured for a component may enter or approve that component.
• •Component marks cannot exceed the configured maximum.
• •A contributor correction creates a controlled new event and does not erase the prior submitted value.

Exception Management

3.7. Pillar 7: Result processing and grace marksPDF p.18

Result processing will remain within the existing SIDH-linked examination result flow. The capability shall consolidate approved CBT, practical and applicable project/OJT components only after reconciliation, apply the authorised result and grace-mark rule for the cycle and publish the authoritative result against the SIDH candidate record. For PM-SETU learners, a validated result event carrying scheme, institution/cluster, trade/course, batch, cycle and source lineage will be published to the common PM-SETU integration/KPI layer.

Functional Capabilities:

Marks consolidation: Use the existing SIDH result workspace to show required components, received values, source, approval status and reconciliation exceptions. For a PM-SETU candidate, the record must retain the SIDH learner / candidate ID and PM-SETU scheme, ITI/cluster, trade/course, batch and cycle context.

• •Prevent result calculation while a mandatory component is missing, unmatched or still under return / correction.
• •Retain the raw component value separately from any derived or grace-adjusted value. Grace and result rules: Configure the approved grace-mark rule and pass / fail conditions by cycle or applicable course / trade.
• •Apply the rule deterministically and record the rule version and any marks adjustment against the candidate result.
• •Do not allow an operator to manually alter the calculated result outside the authorised correction process. Main / Supplementary outcome: Record pass, fail, absent and other approved outcome states.
• •Route eligible failed / absent candidates to the linked Supplementary pool without deleting the Main result.
• •Maintain a separate result record for each examination attempt.

Acceptance Criteria

• •A published result can be recalculated from the retained component marks and rule version.
• •A grace-mark adjustment is separately visible from the original marks.
• •Supplementary participation does not overwrite the Main examination result.

Validation Rules

• •Result calculation requires the mandatory approved component set for the candidate rule.
• •Grace marks cannot exceed the configured policy limit.
• •Published results cannot be changed by ordinary edit; correction requires an authorised result-revision event.

Exception Management

3.8. Pillar 8: Certification and digital recordsPDF p.19

Certification will continue through the existing SIDH digital-record flow. Marksheets and certificates are generated from the published authoritative result, digitally signed, QR-enabled and retained on SIDH. PM-SETU will consume the credential reference / status needed by LMS and programme reporting rather than create a duplicate certificate store; certification events for the PM-SETU cohort will feed the Monitoring and Analytics pipeline after validation.

Functional Capabilities:

Document generation: Generate the marksheet and certificate through the existing SIDH certification flow only from a published eligible result and the approved document template / metadata; publish the resulting credential reference/status to PM-SETU consumers without duplicating the document as a new system of record.

• •Embed the certificate / marksheet identifier, digital signature information and QR verification reference.
• •Link the document to the candidate, trade, examination cycle, result version and issuing authority. Permanent availability: Publish the digital document to the candidate record on SIDH and maintain the historical version even where a later correction or reissue occurs.
• •Provide authorised verification of certificate validity through the QR / verification reference. Project-work certificate: Support the separate project-work certificate where the approved course rule requires it, while maintaining linkage to the main candidate record.

Acceptance Criteria

• •A certificate cannot be generated before the qualifying result is published.
• •The QR / verification reference resolves to the same document status and candidate / result reference recorded in the system.
• •Historical documents remain traceable after correction, reissue or later candidate lifecycle events.

Validation Rules

• •Document generation must use the approved result version and template version.
• •The digital signature must complete successfully before the document is exposed as final.
• •A revoked or superseded document must not appear as the current valid version.

Exception Management

3.9. Pillar 9: Integration, fees and auditPDF p.20

Integration is the core PM-SETU requirement for Exam Management. SIDH remains the examination-facing source of truth, while State processes, NIMI and the examination agency continue to own their respective operational records. The integration pillar shall manage the PM-SETU participation mapping, common identifiers, API / controlled batch exchange, source lineage, validation, retries and reconciliation, and publish validated exam events to the common PM-SETU canonical data / KPI layer. LMS, Monitoring and Analytics are consumers of those events within their own boundaries and cannot alter the authoritative SIDH examination record. Fee configuration and end-to-end audit remain part of the same reconciliation boundary.

Functional Capabilities:

API and source ownership: Use a governed SIDH / PM-SETU Integration Gateway and controlled file-exchange route for candidate data, PM-SETU scheme mapping, centre / shift status, CBT/practical marks, result and certification events. Preserve source system, source identifier, SIDH learner / candidate ID, PM-SETU context, receipt time, validation status and reconciliation outcome.

• •Retain the original source identifier, payload / file reference, receipt time, validation status and reconciliation outcome for each exchange.
• •Reject or quarantine an event that cannot be matched rather than guessing the target candidate or cycle. Fee configuration and status: PM-SETU will not introduce a separate scheme-specific examination fee solely because a learner is identified under PM-SETU. Existing DGT/SIDH fee rules and collection arrangements for CBT, practical and Supplementary examinations will continue to apply, subject to the approved examination policy.
• •The Exam Management integration shall consume and display the applicable fee / payment status required for registration and examination processing, without becoming the financial system of record or creating an additional PM-SETU payment flow.
• •Where a future policy decision changes a fee or introduces a PM-SETU-specific treatment, the change shall be configurable and effective-dated; the original payment / collection reference and source system shall be retained for reconciliation and audit. Audit and exception management: Record every material configuration change, eligibility decision, approval, marks submission, marks correction, result publication and certificate event with actor / source and timestamp.
• •Provide role-specific exception queues for identity, eligibility, centre mapping, question- bank, marks and document-generation failures.
• •Support retry only where the interface contract allows it and prevent duplicate events from changing the candidate state twice.

Acceptance Criteria

• •Every external record displayed in the exam module identifies its source and last successful exchange.
• •Any fee status used to permit registration can be traced to the applicable DGT/SIDH fee rule and the corresponding payment / collection reference; no separate PM-SETU fee record is required unless introduced through an approved policy change.
• •A complete examination result and certificate can be reconstructed from the retained audit history.

Validation Rules

• •Machine-to-machine interfaces must authenticate and be restricted to the approved data contract.
• •Duplicate external events must be idempotent and cannot create duplicate candidate marks or results.
• •A manual correction must identify the user, reason and prior value.

Exception Management

4. Solution ArchitecturePDF p.22

The PM-SETU Exam Management design is an integration architecture centred on the existing SIDH Exam Portal, not a separate examination application. SIDH remains authoritative for the examination-facing candidate record, examination registration/status, result, marksheet and certificate. Existing State, NIMI and examination-agency flows continue to interact with SIDH under their current operating responsibilities. PM-SETU adds a governed scheme-identification and data-exchange layer so that the relevant SIDH examination records can be isolated for the programme, reconciled with learner/ITI/cluster context and distributed to the other PM-SETU systems without duplicate data entry.

Architecture / overviewPDF p.22

Tap to enlarge

4.1. Data layerPDF p.22

The Data Layer does not create a new master learner or examination record. The authoritative person-level reference is the SIDH learner / candidate ID. A canonical PM-SETU mapping links that ID to scheme participation, ITI, Hub-and-Spoke cluster, trade/course, batch and examination cycle while preserving every external source identifier. Examination events retained for PM-SETU integration include eligibility decision, centre/shift, attendance/appearance, practical and project/OJT component status where applicable, CBT marks reference, result status, pass/fail outcome, marksheet/certificate reference, source timestamp, validation status and audit lineage. The exact SIDH field used as the PM-SETU scheme marker is to be confirmed in the production data contract.

Validated examination data generated through SIDH shall be brought forward to the wider PM- SETU ecosystem through governed API calls / event exchanges and, where required, controlled batch interfaces via the common Integration Gateway and canonical PM-SETU data / KPI layer. The published dataset shall include, as applicable, examination registration and eligibility status, centre / shift allotment, examination appearance, CBT and practical / project-OJT assessment status, marks and result status, pass / fail outcome, Supplementary status, and marksheet / certificate references, together with the SIDH learner / candidate ID, PM-SETU programme context, source identifier, timestamp, validation status and lineage. LMS shall consume the learner-facing examination, result and credential references; Monitoring shall consume approved examination KPI / milestone evidence; and Analytics shall consume reconciled examination participation, pass-rate, result and certification measures for leadership dashboards and reports. Downstream PM-SETU platforms remain read-only with respect to the authoritative SIDH examination record. Where reports or dashboards require examination data, the data shall be retrieved from this governed canonical dataset through approved APIs rather than through manual re-entry or ungoverned extracts.

4.2. Platform layerPDF p.23

The Platform Layer is primarily the existing SIDH examination capability and its established role workspaces. PM-SETU requirements are implemented through configuration and extensions required for scheme-level cohort resolution, PM-SETU filters, traceable data contracts, workflow status and event publication. The nine functional pillars in Section 3 describe those requirements while preserving current ownership of State practical execution, NIMI question- bank governance and examination-agency CBT operations.

4.3. Integration and interoperability layerPDF p.23

The Integration and Interoperability Layer connects SIDH Exam Portal with the wider PM-SETU ecosystem through versioned APIs, events/webhooks where supported and controlled batch exchange where required. Every exchange carries common identifiers and source lineage and is subject to schema validation, duplicate control, retry, quarantine and reconciliation. Validated SIDH examination events for PM-SETU are written to the canonical PM-SETU data / KPI layer. LMS consumes examination, result and credential references needed for the learner lifecycle; Monitoring consumes approved KPI / milestone evidence; Analytics consumes reconciled exam appearance, pass-rate, result and certification measures. These consumers remain read-only with respect to the authoritative SIDH examination result.

4.4. User access layerPDF p.23

The User Access Layer continues to use the existing SIDH / examination role model and entity scope. Candidates see only their own eligibility, allotment, result and documents; ITI, examiner and Nodal users are constrained to assigned institutions, batches and events; State users are constrained to State review and practical execution; and DGT, NIMI and examination-agency users receive only the functions required by their roles. PM-SETU administrative views filter records by the validated scheme participation and entity context. Access to Monitoring or Analytics does not confer permission to alter SIDH marks, results or certificates.

5. Non-functional RequirementsPDF p.23

The SIDH-integrated examination capability will operate at national scale during short, high- concurrency windows and will hold sensitive identity, assessment and certification records. PM- SETU integration must therefore preserve SIDH performance and security characteristics while adding scheme-aware filtering, resilient data exchange, integrity of the PM-SETU identifier mapping and complete auditability of every event exported to downstream platforms.

5.1. Performance requirementsPDF p.23

5.2. Security requirementsPDF p.24

• •Government-approved authentication and multi-factor authentication shall be enforced for privileged administrative, examiner, Nodal, State and examination-control roles.
• •Role and entity scope shall be enforced at service / query level so that a user cannot retrieve a candidate or batch merely by changing a URL or identifier.
• •Question banks, generated papers and unreleased result data shall be treated as restricted examination material with least-privilege access and complete access logging.
• •Marks and published results shall be immutable under ordinary user functions; authorised corrections shall create a controlled revision with prior value, reason, actor and approval.
• •Data in transit and at rest shall use approved encryption and key-management controls; integration credentials shall be managed separately from end-user credentials.

5.3. Availability and disaster recovery requirementsPDF p.24

• •Critical examination-control, candidate-allotment, practical-marks and result services shall have a documented recovery objective aligned to the examination calendar.
• •Planned maintenance shall avoid published examination, marks-upload and result windows unless an approved exception has been communicated.
• •The solution shall support failover and restoration testing for the database, object / document store, integration gateway and digital-certificate services.
• •An external dependency failure shall not cause the system to infer a candidate result; the last confirmed state and the affected dependency shall remain visible.

5.4. Backup and data retention requirementsPDF p.24

• •Candidate examination, marks, result and certificate history shall be retained according to the programme / statutory retention policy and shall not disappear from the learner record merely because the cycle is closed.
• •Backups shall protect both operational data and the audit / document evidence needed to reconstruct a published result.
• •Question-bank and paper artefacts shall follow the approved restricted-content retention and disposal rule rather than the general learner-record policy.

5.5. Audit logging and monitoring requirementsPDF p.24

• •Every login, configuration change, candidate-freeze event, centre approval, marks submission, marks correction, result publication and document issuance shall be logged with actor / source, scope, timestamp and outcome.
• •Operational monitoring shall identify failed integrations, unmatched marks, overdue practical batches, unsigned certificates and other conditions that can block result readiness.
• •Audit logs shall be tamper-evident and retained separately from ordinary application edit functions.

5.6. Compliance requirementsPDF p.24

• •The platform shall implement the approved Government security, privacy, accessibility and records-management requirements applicable to the final hosting environment.
• •Candidate identity and examination data shall be processed only for the authorised examination purpose and exposed on a need-to-know basis.
• •Digital signatures, QR verification and certificate generation shall use the authority, document format and verification mechanism formally approved for CTS certification.
• •State-specific examination rules shall be configuration where they legitimately vary, while national result and certificate rules shall remain under the authorised central control.

6. Testing Strategy and Deployment ApproachPDF p.25

6.1. Testing strategyPDF p.25

Testing shall follow the examination lifecycle rather than isolated screens. The programme should first establish deterministic unit and service tests for cycle rules, eligibility, marks consolidation and result calculation; then exercise complete integration scenarios across SIDH, NIMI / question-bank exchange, the examination agency and State / practical workflows. Volume and failover testing should be run against the peak examination windows before any national rollout.

6.2. Acceptance criteriaPDF p.25

• •A PM-SETU eligible candidate can be traced using the same SIDH learner / candidate ID from the SIDH source record through registration, approved centre / shift, marks components, result and certificate, together with the PM-SETU scheme, ITI/cluster, trade/course, batch and cycle context, without duplicate identity creation.
• •A candidate who fails the configured eligibility rule cannot enter the frozen examination universe through an ordinary user action.
• •A generated CBT paper can be traced to the approved NIMI bank and generation-rule version without exposing restricted question content to unauthorised roles.
• •Every CBT mark, practical mark and project / OJT component accepted for scoring is attributable to its source and SIDH examination event, and any PM-SETU event published downstream carries the common learner and programme context plus validation status.
• •A result cannot be published while a mandatory component or reconciliation exception remains unresolved.
• •A digitally signed, QR-enabled marksheet / certificate is generated only from the published approved result and remains available on the SIDH candidate record.

6.3. CI/CD and deployment approachPDF p.25

The platform should be deployed through controlled environments for development, integration testing, user acceptance and production. Configuration such as eligibility thresholds, cycle dates, State centre restrictions, trade applicability and grace rules should move through an approved configuration process rather than direct production edits. Releases during an active examination window should be restricted to approved critical fixes, with rollback and database migration plans tested beforehand.

Rollout should begin with a representative examination cycle covering the key course durations, at least one State with standard centre rules and one State with a specific centre restriction, and both CBT and practical marks exchange. National scale-up should follow successful reconciliation of candidate counts, centre allotments, marks and digital certificates across the pilot cycle.

7. Process Designs and MockupsPDF p.26

The following process designs show the existing SIDH-linked examination workflows with the PM-SETU integration points made explicit. They are not intended to replace the current SIDH flows. Each process preserves the authoritative SIDH candidate/result record, uses the SIDH learner / candidate ID plus PM-SETU participation context to identify the scheme cohort, and publishes validated programme-relevant events to the PM-SETU integration/KPI layer for LMS, Monitoring and Analytics. Mockups are illustrative views of the same integrated operating model.

7.1. Exam cycle configuration and candidate eligibilityPDF p.26

The existing SIDH cycle / eligibility process is reused. The PM-SETU addition is to resolve the candidate against the SIDH learner / candidate ID and PM-SETU participation mapping before the valid examination universe is frozen; incomplete attendance / FA or unresolved scheme mapping is held as an exception rather than inferred.

BPMN / process flowPDF p.26

Tap to enlarge

Wireframe / screenPDF p.27

Tap to enlarge

7.2. Question bank and CBT paper generationPDF p.28

Question development and CBT delivery remain the existing NIMI / examination-agency flow linked to the SIDH examination cycle. PM-SETU adds common cohort/cycle identifiers and publishes only non-restricted validated outcome events to the programme data layer.

BPMN / process flowPDF p.28

Tap to enlarge

Wireframe / screenPDF p.28

Tap to enlarge

7.3. Centre mapping and CBT executionPDF p.29

Centre mapping and CBT execution remain within the existing examination-agency, State and SIDH flow. PM-SETU candidates are filtered from the frozen SIDH universe using the scheme mapping, and approved allotment / appearance / marks events are made available to downstream programme reporting after validation.

BPMN / process flowPDF p.29

Tap to enlarge

Wireframe / screenPDF p.29

Tap to enlarge

7.4. Practical examination and project / OJT assessmentPDF p.30

The practical process remains State-led and SIDH-linked: examiner and venue are assigned, the practical is conducted, marks are entered and the mapped batch is approved. The PM- SETU layer uses the same SIDH learner / candidate ID and programme context and exports only approved component events needed by result processing, Monitoring and Analytics.

BPMN / process flowPDF p.30

Tap to enlarge

Wireframe / screenPDF p.30

Tap to enlarge

7.5. Result, certification and supplementary routingPDF p.31

Result processing begins in the existing SIDH result workflow only after required components reconcile. The approved result / grace rule is applied, SIDH publishes the authoritative result and digital documents, and eligible failed / absent candidates are routed to Supplementary without overwriting the Main result. For PM-SETU candidates, the published result and certification events are then sent to the common PM-SETU data/KPI layer for LMS, Monitoring and Analytics.

BPMN / process flowPDF p.31

Tap to enlarge

Wireframe / screenPDF p.31

Tap to enlarge