DWSS, TC(W) 8/2025, DSR v1.2, and iCWP — Answered

All DEVB capital works contracts — both GCC and NEC forms — tendered on or after 1 April 2026 must use a DWSS that satisfies every provision of DEVB TC(W) No. 8/2025.

This replaces the previous regime under TC(W) No. 2/2004 (General Conditions of Contract projects) and TC(W) No. 6/2015 (NEC projects). Contracts tendered before 1 April 2026 continue under the pre-existing circulars.

DWSS implements all mandatory requirements across the three core components defined by TC(W) 8/2025:

• Component I — Workflow Management (§ 7): Six digitised supervision modules with full approval lifecycle, audit trails, and statistical dashboards.
• Component II — Smart Construction Management (§ 8): IoT telemetry hub amalgamating all SSSS vendor data, real-time alert engine, and SCM dashboards.
• Component III — Smart Document Management (§ 9): WBTC 19/93-compliant document control, version history, OCR, and external reviewer portal.

Every state transition writes an append-only audit record. All data is exportable to iCWP within 24 hours of capture.

TC(W) 8/2025 defines three mandatory DWSS components:

• Workflow Management — Digital processing of six site supervision forms (RISC, Site Diary, Safety, Cleansing, Labour Return, NEC Contract Management).
• Smart Construction Management — Centralised hub for real-time IoT and SSSS telemetry, with threshold-based alerting.
• Smart Document Management — Web-based document lifecycle management following WBTC No. 19/93.

Yes. DWSS handles both GCC and NEC contracts natively:

• GCC contracts: RISC forms referencing PAH 2024 Appendix 7.82A (SI/SUR/EM types), G.F. 536 Site Diary, and G.F. 527 Labour Return.
• NEC contracts: RISC forms referencing PAH 2024 Appendix 7.82B, plus full NEC administration — Compensation Events, Early Warnings, Project Manager's Instructions, Payment Certificates, and the NEC Health Check data model.

DEVB TC(W) No. 8/2025 applies to all capital works contracts tendered on or after 1 April 2026. It supersedes both TC(W) 2/2004 and TC(W) 6/2015. The requirement for SSSS to be amalgamated into DWSS (previously optional under TC(W) 3/2023) also became mandatory from this date.

DWSS is built to HKSARG IT Security requirements, including:

• Multi-factor authentication (TOTP)
• 12-character minimum password policy
• Account lockout after repeated failed attempts
• 30-minute idle session timeout
• Append-only audit logs — no modification or deletion of records
• TLS 1.2+ for all data transport

The Data Standardisation Report (DSR), currently at Version 1.2 (December 2025), is the DEVB technical specification that defines:

• XML schemas and data fields for each supervision module
• File naming conventions and encoding requirements
• Transport protocols for DWSS-to-iCWP data exchange
• Baseline dashboard visualisation requirements
• New in v1.2: Contractor's Submission (§ 4.10), Raw Document Metadata (§ 4.11), and NEC Health Check data model (§ 4.8 G)

DWSS is fully architected against DSR v1.2, covering all 8 standardised data modules.

DWSS uses XML as the primary format for iCWP export (DSR § 4.1.1), delivered via SFTP. A RESTful JSON API and SOAP interface are also supported.

All data is encoded in UTF-8 with HKSCS (ISO/IEC 10646 + Hong Kong Supplementary Character Set) to ensure full support for Traditional Chinese characters used in project documentation.

DSR v1.2 § 4.1.2 specifies the following file naming convention:

ProjectNo-ContractNo-DatasetID-Timestamp.xml

For example: 461TH-HY_2014_09-DWSS-RISC-01-20260524T083210.xml

Note that forward slashes in contract numbers are replaced with underscores (e.g. HY/2014/09 becomes HY_2014_09). Timestamps use ISO 8601 format in UTC+8.

All data captured in DWSS is exported to iCWP within 24 hours of capture (DSR § 1.4). DWSS supports incremental sync — only records modified since the last successful sync are exported, using a last_sync_time parameter.

For SCM telemetry, events are available via the GET /scm/api/events/ endpoint in paginated form for near-real-time iCWP pull.

DSR v1.2 standardises 8 data modules, expanding from the 6 modules in the previous version:

• § 4.3 — RISC Forms
• § 4.4 — Site Diary
• § 4.5 — Site Safety Inspection Records
• § 4.6 — Cleansing Inspection Records
• § 4.7 — Labour Return Statistics
• § 4.8 — Contract Management (incl. NEC Health Check — new in v1.2)
• § 4.10 — Contractor's Submission (new in v1.2)
• § 4.11 — Raw Document Metadata (new in v1.2)

DSR Version 1.2 (December 2025) introduced three major additions:

• NEC Health Check data model (§ 4.8 G): A six-dimension performance assessment covering financial, time performance, programme, early warnings, compensation events, and contract info — transmitted to iCWP for portfolio-level governance.
• Contractor's Submission module (§ 4.10): Standardised schema for contractor submissions managed through SDM.
• Raw Document Metadata module (§ 4.11): Structured metadata export for all SDM-managed documents, completing the Smart Document Management interface to iCWP.

These additions expanded the iCWP interface from 6 to 8 standardised data modules.

DSR v1.2 § 3 defines a baseline set of statistical dashboards that every DWSS must provide — one per workflow module. DWSS fulfils these requirements with fully drill-down interactive charts:

• RISC: NC distribution pie, failure rate trend, outstanding count bar (§ 3.2)
• Site Diary: Overdue distribution, completion status, top-4 overdue ranking (§ 3.3)
• Safety: NC/near-miss count trend, top-4 non-compliance, accident rate (§ 3.4)
• Cleansing: DCI/WCI completion status, non-compliance count, elapsed time (§ 3.5)
• Labour Return: Wage increase trend, labour by trade code (§ 3.6)
• Contract: Early Warning trend, key dates timeline, CE/PMI breakdown (§ 3.7)

All dashboards support daily, weekly, monthly, and yearly views via mouse-wheel zoom, with drill-down to individual project and record level.

TC(W) 8/2025 § 7.5.1 requires all six of the following modules:

• (i) RISC Form — Request for Inspection & Survey Check, implementing PAH 2024 Appendix 7.82A (GCC) and 7.82B (NEC) with full revision/resubmission cycle.
• (ii) Site Diary — G.F. 536 Contractor Diary and Supervisor Site Record Book with daily progress, weather, and labour entries.
• (iii) Safety & Environmental Inspection — Weekly safety walk and environmental inspection checklists with non-compliance correction log.
• (iv) Cleansing Inspection — Daily (DCI) and Weekly (WCI) Cleansing Inspection Checklists tracking offences and non-compliance counts.
• (v) Labour Return — G.F. 527 monthly labour return in both Rev 2003 and Rev 2017 formats.
• (vi) NEC Contract Management — CE, EW, PMI, PMC workflows, programme tracking, and NEC Health Check.

The RISC (Request for Inspection & Survey Check) form follows a three-party workflow:

• Contractor creates and submits the RISC form, attaching GPS-tagged photos with HK80 coordinate metadata.
• Supervisor reviews and either passes, fails, or requests a revision. A failed RISC triggers a new revision cycle linked to the parent RISC.
• Acknowledgement is issued on completion to close the form.

Form types supported: SI (Structural Inspection), SUR (Survey), and EM (Emergency). Pass/fail rate and outstanding RISC dashboards are updated in real time.

The Smart Site Safety System (SSSS), governed by TC(W) No. 3/2023, encompasses IoT-based safety monitoring devices deployed on construction sites — AI cameras, worker wearables, e-locks, mobile plant zone alert systems, PTW systems, and a Centralised Management Platform (CMP).

From 1 April 2026, TC(W) 8/2025 mandates ("shall", upgraded from the previously optional "may" in TC(W) 3/2023) that SSSS be amalgamated into DWSS as its Smart Construction Management hub. Any SSSS vendor can connect by obtaining a vendor token and using the DWSS ingest API (POST /scm/api/ingest/events/).

The SCM alert engine classifies inbound telemetry into three severity levels:

• INFO — Telemetry within normal range. Logged for audit only. No alert raised.
• WARNING — Value exceeds the defined threshold × 1.0. Alert raised and assigned officer notified by in-app notification and email.
• CRITICAL — Value exceeds threshold × 1.5 (AAA level). Supervisor and CRE are also notified immediately alongside the assigned officer.

Monitoring categories include: Progress, Safety, Deformation, Material, Machinery, and Environmental monitoring.

DWSS SCM supports all 10 SSSS device categories defined in TC(W) 3/2023:

• AI Safety Camera (AI Safety Monitoring / CCTV)
• Smart Worker Wearable
• Access Control (E-lock)
• Mobile Plant Danger Zone alert
• Tower Crane Lifting Zone alert
• Digital Permit-to-Work (PTW)
• Plant & Tool Tracking
• Confined Space Gas Monitor
• Deformation / Settlement sensors
• SSSS Centralised Management Platform (CMP) Gateway

DWSS SDM uses Tesseract-powered OCR on every uploaded document (TC(W) 8/2025 § 9.4.5). The extracted text is stored in PostgreSQL for full-text search across the entire document archive.

Image-based PDFs (scanned documents) are automatically converted to searchable PDFs. The original file is preserved alongside the OCR-processed version, and both are versioned together under the same DocumentVersion record.

TC(W) 8/2025 § 9.7 requires SDM to allow external reviewers (non-DWSS users) to access specific documents without creating a full platform account. DWSS implements this via an OTP portal:

• A DWSS user assigns a document to an external reviewer and enters their email address.
• The reviewer receives a tokenised invitation link by email.
• Clicking the link prompts for a 6-digit OTP (15-minute TTL) sent to the same address.
• Upon successful OTP entry, the reviewer gets a 2-hour read-only session scoped to their assigned document only — no access to other records.

WBTC No. 19/93 defines a four-level file reference system. DWSS SDM implements this as a strict four-level hierarchy:

• L1 Cabinet — Project / Contract Identifier (e.g. R9K/2003/09)
• L2 Drawer — File Division (e.g. M30)
• L3 Folder — File Number / Extension (e.g. 200/12)
• L4 Document (Folio) — Auto-assigned 5-digit folio (e.g. 00001)

A full document reference reads: R9K/2003/09/M30/200/12/00001. All SDM-managed documents carry this reference and are included in the DSR v1.2 § 4.11 Raw Document Metadata iCWP export.

First standardised in DSR v1.2 (December 2025), the NEC Health Check is a six-dimension structured performance assessment transmitted to iCWP for portfolio-level contract governance:

• Financial — Tender/contract prices, pain/gain share, expenditure %, CE cost impacts
• Time Performance — Duration elapsed, key date achievements, EOT analysis, sectional completion
• Programme — Submission/acceptance compliance, revision intervals, average processing times
• Early Warnings — EW by source, closure rates, age analysis, average resolution timelines
• Compensation Events — Notification stats, implementation rates, processing timelines, pending CE age
• Contract Info — Department, NEC version/options, contractor, consultant, key personnel

Every file upload in DWSS SDM creates a new DocumentVersion record containing:

• Auto-incremented version number
• Uploader identity and upload timestamp
• A mandatory change note describing the revision
• Full-text OCR of the uploaded file

Documents can be frozen (§ 9.8.9) — frozen documents reject further uploads until an administrator explicitly unfreezes them. The complete version history is preserved and immutable, meeting the append-only audit requirements of TC(W) 8/2025.

DWSS integrates with iCWP (integrated Construction Works Platform) through two primary channels:

• SFTP XML Push: Incremental DSR-compliant XML files are pushed via SFTP within 24 hours of data capture. Files follow the DSR v1.2 naming convention and UTF-8/HKSCS encoding.
• RESTful HTTPS API: iCWP can pull data directly using GET endpoints with OAuth 2.0 Bearer Token or API Key authentication, filtering by contract, status, and date range.

All 8 standardised modules (§§ 4.3–4.11) are available through both channels.

The DWSS API supports two authentication methods:

• OAuth 2.0 Bearer Token — Recommended for iCWP system-to-system integration. Tokens are scoped per contract and module.
• API Key — Available for trusted integrations. Passed via the Authorization header.

All API traffic is encrypted with TLS 1.2+. Timestamps in API responses use ISO 8601 format in UTC+8.

Key DWSS API endpoints include:

• GET /api/v1/{module}/records — Incremental sync; filter by contract, status, and date range.
• GET /api/v1/attachments/{file_id} — Pre-signed attachment URL (30-minute expiry).
• POST /scm/api/ingest/events/ — SSSS vendor telemetry ingest (vendor token authenticated).
• GET /scm/api/events/ — Paginated telemetry event list for iCWP pull.
• GET /scm/api/alerts/ — Paginated safety alert list.

Module identifiers for {module}: RISC, SITE_DIARY, SAFETY_INSP, CLEAN_INSP, LABOUR_RETURN, CONTRACT, CONTRACTOR_SUB, DOC_METADATA.

Yes. DWSS SCM is vendor-agnostic. Any SSSS vendor — regardless of device brand or proprietary platform — can connect by obtaining a DWSS vendor token and using the standard ingest API (POST /scm/api/ingest/events/).

Each vendor token is scoped to specific device categories and the contracted project. Telemetry from multiple vendors is consolidated into the unified DWSS SCM dashboard and alert engine, with clear source attribution per event.

DWSS uses a last_sync_time parameter for incremental exports. On each sync cycle:

• Only records created or modified since the last successful sync are included in the export.
• XML files are generated with a new timestamp in the filename.
• A sync log entry is written with the record count, module, contract, and outcome.
• Failed sync attempts are retried automatically and logged for administrator review.

This design ensures iCWP always receives a complete, non-duplicated, ordered dataset without requiring full re-exports.

Yes. Photo attachments — including GPS-tagged RISC inspection photos with HK80 coordinate metadata, and before/after safety inspection photos — are included in iCWP exports.

For API access, attachments are served via pre-signed URLs (GET /api/v1/attachments/{file_id}) with a 30-minute expiry. For SFTP XML exports, attachment metadata (filename, size, MIME type, checksum) is embedded in the XML record, and the binary files are uploaded to the designated SFTP path alongside the XML.