DOCUMENT CONTROL AND INDEX

TABLE OF CONTENTS

INTRODUCTION, PURPOSE AND SCOPE

1. INTRODUCTION

The institutional Learning Management System (LMS) supports curriculum delivery, elective workflows, subject and faculty allocation, timetable publication, attendance, course materials, lesson plans, assignments, mentoring and academic communication. This policy establishes a database-first, role-based, auditable and mobile-responsive governance model in which digital workflows support—not replace—authorised academic decision-making.

2. PURPOSE

To ensure that LMS services are reliable, secure, inclusive, educationally effective and fully traceable, and that every important role-to-role communication and operational action is recorded in the database.

3. SCOPE

Students, faculty, mentors, HODs, Deans, IQAC, Admin, Principal, COE, technical staff and all LMS modules, integrations, records, notifications, email communications, reports and advisory AI analytics.

OBJECTIVES

4. OBJECTIVES

• Provide a single dependable digital environment for approved academic workflows and learning resources.
• Ensure role-based access, database persistence, auditability and protection of core/master data.
• Maintain independence of OE, PE, subject allocation and timetable modules while enabling authorised data reuse.
• Support transparent communication, deadlines, reminders, escalation and publication between roles.
• Protect attendance, marks, assignment, mentoring and student data through approved controls.
• Provide responsive, accessible and mobile-friendly interfaces with human-reviewed advisory analytics.

POLICY FRAMEWORK

5. GUIDING PRINCIPLES

1. Database records are the system of record; page/session-only state shall not represent a completed institutional action.
2. Core, master, configuration and protected records shall never be deleted or altered during workflow testing or reset.
3. Original student and faculty submissions shall remain unchanged; later decisions shall be stored separately with audit history.
4. Module independence shall be preserved and no artificial dependency shall block valid academic work.
5. Operational decisions belong to authorised humans; AI and conflict engines are advisory unless a deterministic safety rule requires blocking.
6. Every important action, notification, approval, override and publication shall be attributable and time-stamped.

6. GENERAL POLICY COMMITMENT

The Institution shall implement this policy through approved roles, adequate resources, documented procedures, transparent communication and measurable review. Decisions and exceptions shall be recorded and authorized by the competent authority.

LMS GOVERNANCE AND SYSTEM-OF-RECORD RULES

7.1 DATABASE-FIRST OPERATION

• Every completed workflow action shall be saved to an approved database table and shall be readable by authorised role dashboards.
• Important communication between Student, Faculty, Mentor, HOD, Admin, IQAC, Principal, COE and other roles shall be persisted with delivery/status evidence.
• Core/master data shall be read and referenced, not overwritten by workflow decisions.
• Testing may clear only authorised workflow/transaction data; protected master, configuration, audit-critical and important LMS tables shall remain intact.

7.2 SCOPE AND ALIAS RESOLUTION

Every module shall display a visible scope banner showing academic year, regulation, department, year of study, semester and section where applicable. Department aliases shall resolve to the approved canonical department and shall be recorded for audit.

ELECTIVE AND SUBJECT ALLOCATION WORKFLOWS

7.3 OPEN ELECTIVE (OE)

1. Admin/HOD opens an OE preference window with due date and instructions.
2. Students submit preferences; original submissions remain unchanged.
3. At closure, a snapshot is created for HOD analysis.
4. Home HOD confirms OE individually for every student, including non-submitters or justified changes, in a separate confirmation table.
5. Final subject allocation is saved per student and communicated.

7.4 PROFESSIONAL ELECTIVE (PE)

Home HOD confirms one final PE subject per section for each PE slot. Student preference, where collected, remains advisory evidence and shall not be overwritten.

7.5 MODULE INDEPENDENCE

OE, PE, subject entry/allocation and timetable are independent modules. HOD may proceed with any module based on available approved data; timetable creation shall not be blocked by incomplete OE/PE workflows.

FACULTY PREFERENCE AND ALLOCATION

7.6 FACULTY PREFERENCE

1. HOD publishes confirmed subjects to eligible faculty with a due date.
2. Faculty submissions remain unchanged and a closure snapshot is created for analysis.
3. Non-submission by the deadline is notified to the respective HOD, Admin and IQAC.
4. Preferences are advisory; HOD independently allocates faculty based on competence, workload, continuity and departmental need.

7.7 CANONICAL ALLOCATION

lms_faculty_subject_allocations is the canonical faculty allocation table. After allocation, faculty, subject, academic year, semester and section are fixed through the approved workflow and communicated to students and faculty.

7.8 CHANGE CONTROL

Any later allocation change shall preserve the earlier allocation, reason, requesting authority, approving authority, effective time and affected communications.

TIMETABLE, CONFLICT AND CLASS ALTERATION

7.9 TIMETABLE

• HOD selects the subject in the day-order/hour matrix; faculty is fetched from the approved allocation.
• timetable_master, timetable_details and timetable_matrix remain the operational timetable tables; LMS tables may serve as report/audit mirrors.
• Conflict checks shall prevent faculty, room, section, OE-group and student-movement overlaps.
• Advisory alternatives may be shown, but HOD chooses periods independently within valid constraints.
• HOD publishes the timetable and affected users receive the approved version.

7.10 CLASS ALTERATION

Faculty requests alteration. The concerned HOD approves. Where alternate faculty belongs to another department, both HODs approve. Admin may override only with mandatory reason and audit. IQAC has no class-alteration approval role.

ATTENDANCE, MATERIALS AND ASSIGNMENTS

7.11 ATTENDANCE

• Attendance shall use only lms_attendance_sessions, lms_attendance_entries and lms_attendance_audit as the approved operational record set.
• Faculty may edit attendance until 11:59 PM on the same day.
• After the cut-off, reopening by HOD/Admin with a mandatory reason is required.
• Every change shall preserve old value, new value, actor, time and reason.

7.12 COURSE DELIVERY

Faculty shall maintain approved lesson plans, course materials, topic/unit structure and references. Student access shall follow allocation and publication status.

7.13 ASSIGNMENTS

• Upload size shall not exceed 3.5 MB unless revised by approved configuration.
• Allowed formats: PDF, DOC, DOCX, XLS, XLSX, PPT, PPTX, JPG, PNG and ZIP.
• Late submissions are allowed and shall be clearly marked late.
• Original submission time and replacement history shall be retained.

MENTORING, COMMUNICATION AND REPORTING

7.14 MENTORING

The LMS may support student profile, academic concerns, internal/semester marks, NPTEL, skill development, placement readiness and mentoring needs. Basic profile information shall be fetched from master records without unauthorised editing. Mentor diary entries shall record counselling, agreed action, follow-up and confidentiality classification.

7.15 NOTIFICATIONS AND EMAIL

• Important opening, deadline, confirmation, allocation, publication, escalation and approval events shall create database notifications.
• Important events shall also send email where configured.
• Delivery failures shall be logged and shall not erase the in-portal notification.

7.16 PRINT AND EVIDENCE

HOD and Admin shall have print/export views after major stages such as elective confirmation, faculty allocation and timetable publication. Reports shall show scope, version, generated time and approving authority.

AI ANALYTICS AND HUMAN CONTROL

7.17 ADVISORY AI LAYER

• AI analytics is a separate additive advisory/reporting layer for Admin, IQAC, HOD, Faculty and Student views.
• AI shall not autonomously confirm OE/PE, allocate faculty, publish timetable, modify attendance/marks or approve class alterations.
• Recommendations require human review/acceptance and shall be logged.
• AI reads approved LMS data and writes only to dedicated AI insight/audit tables.

7.18 CANONICAL AI TABLES

The approved AI tables are lms_ai_analysis_runs, lms_ai_department_scorecards, lms_ai_faculty_scorecards, lms_ai_subject_scorecards and lms_ai_recommendations. Duplicate tables shall not be created without architecture approval.

7.19 EXPLAINABILITY

AI reports shall identify data period, source, method, limitations and review status. An AI score shall not be used alone for discipline, grading, attendance correction, workload allocation or adverse action.

SECURITY, ACCESSIBILITY AND CHANGE MANAGEMENT

7.20 SECURITY

• Role-based access, CSRF protection, secure sessions, validation, upload controls, encryption where applicable, backups and logs are mandatory.
• Users shall not access another person’s data without role authority and legitimate institutional need.
• Bulk export and sensitive reports shall be restricted and logged.

7.21 RESPONSIVE AND ACCESSIBLE DESIGN

Core workflows shall support desktop and mobile use, readable typography, keyboard access, clear error messages, scope visibility and safe confirmation before irreversible actions.

7.22 RELEASE CONTROL

• Changes shall be tested role-wise and scope-wise using representative departments, years, semesters and sections.
• Database migrations shall be reviewed, backed up and reversible where feasible.
• Production release shall not delete, rename or silently repurpose established operational fields without approved migration and regression testing.

ROLES AND RESPONSIBILITIES

8. ROLES AND RESPONSIBILITIES

• The Principal approves LMS governance and major policy changes.
• Dean Academics owns academic-process alignment and cross-department consistency.
• Admin manages institutional windows, configurations, access and authorised overrides.
• IQAC monitors workflow quality, day order and evidence without taking unauthorised academic approvals.
• HODs make department-level confirmations, faculty allocations, timetable and class-alteration decisions.
• Faculty maintain attendance, materials, lesson plans, assignments and authorised learner records.
• Students submit preferences, assignments and profile/mentoring information honestly and within timelines.
• IT/LMS teams implement security, backups, logs, integrations, availability and change control.

IMPLEMENTATION PROCEDURE

9. IMPLEMENTATION PROCEDURE

1. Configure academic scope, roles, master data and module-specific windows.
2. Collect original user submissions with deadline, acknowledgement and immutable history.
3. Create snapshots after closure where analysis requires a fixed copy.
4. Record authorised confirmations/allocations in separate decision tables.
5. Publish outcomes and communicate them to affected roles through dashboard and email.
6. Operate teaching-learning modules under approved permissions and cut-off rules.
7. Monitor exceptions, reopenings, overrides, conflicts and audit trails.
8. Review performance, security and user feedback before controlled release of changes.

RECORDS AND COMPLIANCE

10. RECORDS AND EVIDENCE

• User roles, scope resolution and access logs
• Elective windows, submissions, snapshots, confirmations and final allocations
• Faculty preferences, allocations and communication records
• Timetable masters/details/matrix, conflicts, publications and alterations
• Attendance sessions, entries, audit, reopenings and reasons
• Materials, lesson plans, assignments, submissions and late status
• Mentor diary, notifications, emails, AI insights and human review decisions

11. MONITORING INDICATORS

• Workflow completion and deadline compliance by role
• Number and resolution time of data-scope or access issues
• Timetable and allocation conflict prevention rate
• Attendance completeness, reopening frequency and audit compliance
• Assignment/material usage and learner engagement
• System availability, mobile usability, security incidents and user satisfaction

12. CONFIDENTIALITY, RETENTION AND ACCESS

Records shall be accurate, retrievable and protected against unauthorized alteration, disclosure or destruction. Access shall be role-based and limited to legitimate institutional need. Retention and disposal shall follow the approved schedule and applicable requirements.

13. NON-COMPLIANCE

Non-compliance may result in corrective action, withdrawal of access or benefit, recovery of loss, disciplinary action, referral to a statutory body or other proportionate action after due process.

REVIEW AND APPROVAL

14. REVIEW AND AMENDMENT

The policy owner shall review this document at the stated cycle or earlier due to changes in law, regulation, institutional structure, technology, risk, audit findings or stakeholder requirements. Amendments shall take effect only after approval and version control.

15. REFERENCES

• Institutional Academic, Examination, OBE, IT, E-Governance, Data Privacy and AI Policies
• Applicable autonomous academic regulations and role permissions
• Approved LMS database architecture, change-control and backup procedures
• Applicable accessibility, cybersecurity and data-protection requirements

16. APPROVAL AND SIGNATURES

This is a controlled institutional document. Printed copies are uncontrolled unless specifically stamped and issued by the authorized office.