AIEE.DEVSOQ TMS CRD
HomeExport PDFOverview

Contents

/
  • 1.1Overview
  • 1.2About AIEE.DEV
  • 1.3Parties & sign-off
  • 2.1Plan SOQ-25K
  • 2.2Max claim (EDG)
  • 2.3Rate card
  • 3.1Discovery pack
  • 3.2Brand & website appendix
  • 4.1Attachment A
  • 4.2PRD
  • 4.3Solution overview
  • 4.4Registration
  • 4.5Admin
  • 4.6CRM & sales
  • 4.7Student & trainer portals
  • 4.8SWDA & finance
  • 4.9Platform
  • 4.10Chat agents
  • 4.11Ops modules
  • 4.12Business benefits
  • 4.13DSMR research
  • 4.14Build vs buy
  • 4.15Market & competitors
  • 5.1Project control plan
  • 5.2Prototype & screens
  • 5.3Capability roadmap
  • 5.4UI/UX
  • 5.5Frontend
  • 5.6Backend
  • 5.7Architecture
  • 5.8Tech spec
  • 5.9Directory structure
  • 5.10Handover pack
AIEE.DEVSOQ TMS / Coding Requirement Documentation
5.8 / 5.8 Tech spec
Pei Han CCO / Eddy CPO / HK CSO / Andy Koh CTOaiee.dev5.8 / Confidential
5. Delivery5.8 Tech spec
Section 5.8

Master Tech Specification

Canonical technical specification for SOQ Training Management System delivery.

Document control

FieldValue
ProductSOQ Training Management System (TMS)
Doc typeMaster Technical Specification (MTS)
Statusv0.2 — SOQ requirements baseline
AudienceSolution managers, product, engineering, compliance

1. Purpose

Define technical principles, module boundaries, quality bars, and acceptance criteria for SOQ TMS — a platform that meets SOQ’s diploma, short course, and WSQ operational requirements with SWDA integration and Xero finance sync.

2. Goals

  1. Deliver SWDA/WSQ-conformant training operations (course runs, enrolments, attendance, assessments).
  2. Operate as three user-facing apps with shared identity and consistent Student 360 data.
  3. Keep SWDA hub and Xero adapter as isolated shared services with full audit trails.
  4. Support CRM -> TMS handoff without losing enquiry-to-enrolment history.
  5. Meet PDPA-aligned governance: consent, access logs, retention, audit.

3. Non-goals (v1)

#Requirement
1Full talent marketplace / job matching (DSMR ai.HumanCapital scope)
2AI proctoring at D-GENIO depth (unless added in later phase)
3Multi-country funding adapters beyond Singapore SWDA/WSQ
4Native mobile apps (responsive web first)
5Replacing Xero as general ledger

4. Design principles

  1. TMS is operational source of truth for enrolment, attendance, assessment, pricing, orders.
  2. Adapter over embed — no direct SWDA API calls from UI controllers.
  3. Evidence before funding — claims blocked until attendance/assessment thresholds met.
  4. Configurable policy — e.g. 18-month exemption rule as admin config, not hard-coded.
  5. Audit by construction — money, grades, grant states, and PII access are append-only logged.

5. Quality bars

AreaTarget
Availability99.9% monthly (business hours critical paths)
SWDA submissionsIdempotent keys; exactly-once effect
Registration/paymentPCI via gateway; no card data in TMS DB
AccessibilityWCAG 2.2 AA on student and public flows
ObservabilityTrace ID from registration -> SWDA submission

6. Suggested stack

LayerChoice
Web appsNext.js + TypeScript (Admin, Student, Trainer, Public site)
APINode (NestJS) or .NET — team preference
DatabasePostgreSQL
QueueRedis + workers for SWDA/Xero async jobs
FilesS3-compatible (documents, recordings, SCORM)
AuthOIDC + Singpass adapter + MFA for staff
AccountingXero API (official connector patterns)

7. Security baseline

#Requirement
1RBAC per Section 10.1 roles
2Secrets in vault; SWDA credentials never in frontend
3Data residency Singapore default
4ISO 27001-aligned control roadmap

8. MTS completion checklist

#Requirement
1[x] DSMR suite researched
2[x] SOQ functional requirements documented
3[x] DSMR vs SOQ comparison
4[ ] SWDA API inventory from SOQ subscriptions
5[ ] TPGateway/SWDA field mapping spreadsheet
6[ ] Xero chart-of-accounts mapping workshop
7[ ] Threat model v1
8[ ] MVP screens (WSQ registration + admin enrolment)
5.7 Architecture5.9 Directory structure

aiee.dev / Confidential

AIEE.DEV