Urban Studies Programme
Jointly organized by The Department of Geography and Resource Management and
The School of Architecture, Faculty of Social Science, The Chinese University of Hong Kong
URSP3600
DESIGNING SMART CITIES:
SYSTEMS, DATA, AND INTELLIGENT URBAN SERVICES
Term 1, 2026–27
Instructor: Dr. Tat Lam
Venue: CKB UG05
Time: Mondays 09:30-12:15
Course Description
URSP3600 Designing Smart Cities: Systems, Data, and Intelligent Urban Services is a workshop-based undergraduate course that introduces students to the design, architecture, and prototyping of smart city systems. Rather than surveying smart city discourse from a distance, this course places students at the centre of the making process: over the course of the semester, each student or team will progressively design, develop, and present a smart city system, smart urban service, or intelligent urban application of their own choosing.
A smart city is understood in this course not as a brand, a political slogan, or a futuristic image, but as a connected urban system in which problems are identified, users and stakeholders are defined, data is gathered or accessed, information is structured, workflows are built, decisions are supported, and services are delivered so as to create public, institutional, or commercial value. The central questions of the course are: What makes an urban system genuinely "smart"? How do data, Building Information Modelling (BIM), digital twins, sensors, APIs, platforms, AI workflows, and user interfaces work together? And how can undergraduate students design and build their own intelligent urban system, application, or service?
The course is deliberately practical and accessible. Students are not expected to arrive with advanced programming knowledge, specialist urban theory, or prior experience in software engineering. Instead, they are expected to be curious, willing to learn through making, and ready to engage with the current ecosystem of AI tools, no-code and low-code platforms, open datasets, APIs, and digital workflows that make it possible for undergraduates to build substantive urban technology projects. The course introduces ideas step by step and immediately connects each concept to workshop activity.
Each weekly session is structured around a short lecture or conceptual presentation followed by a guided workshop in which students apply the week's ideas directly to their own emerging project. Topics covered across the semester include smart city foundations, Building Information Modelling (BIM) and information-rich urban systems, digital twin logic, open urban data and government APIs, IoT and sensing, AI agents and workflow design, interface and dashboard development, and the social and entrepreneurial value of intelligent urban systems.
Students may develop their projects by building on a shared course repository of datasets, APIs, scripts, workflows, BIM and digital twin references, and AI resources — including relevant Hong Kong open data such as the Smart City Blueprint 2.0, Development Bureau datasets, Buildings Department building records, Lands Department Location Search API, Transport Department parking vacancy data, and Environmental Protection Department air quality data — or by developing project-specific resources of their own. This flexibility is fundamental to the course: students are encouraged to select the tools, platforms, and data sources most appropriate to their project idea.
The course culminates in a final presentation with a demonstrator, prototype, or proof of concept, supported by an individual reflection. By the end of the semester, students should be able to identify an urban problem, articulate a system logic, connect appropriate data and technology components, and communicate the value of their proposal clearly and professionally.
Course Aims
This course aims to:
-- develop students' understanding of smart city systems as integrated assemblages of data, sensors, information models, digital workflows, AI, platforms, and user-facing services;
-- introduce Building Information Modelling (BIM) and digital twin concepts as foundational components of intelligent urban and building management;
-- build students' capacity to identify urban problems and frame them as system design challenges;
-- equip students with practical skills in accessing open data, APIs, AI tools, and no-code/low-code workflows so that they can prototype intelligent urban services;
-- foster students' ability to evaluate the social, institutional, and entrepreneurial value of smart city systems; and
-- support progressive, workshop-based learning through which students build a coherent smart city project from concept to prototype over the course of the semester.
Expected Learning Outcomes
Upon successful completion of this course, students will be able to:
-- Explain key smart city concepts including BIM, digital twins, urban data, APIs, IoT, AI agents and workflows, and platform-based urban services.
-- Identify and frame an urban problem that can be addressed through a smart system, and articulate a clear problem statement, user group, and system response.
-- Analyse how data, information models, software platforms, APIs, sensors, and AI workflows can be combined into a coherent intelligent urban system.
-- Evaluate the role of Building Information Modelling (BIM) and digital twin logic in the design, construction, management, and operation of buildings, districts, and urban services.
-- Develop a smart city proposal, system prototype, application, or proof of concept using shared or self-developed datasets, tools, scripts, code, and AI-assisted workflows.
-- Assess the technical, social, and entrepreneurial value of a smart city system, including consideration of users, stakeholders, public benefit, and implementation feasibility.
-- Communicate system logic, interface design, and implementation value effectively through slides, diagrams, and oral presentation.
-- Work independently or collaboratively in a workshop setting to iteratively build, test, and refine an intelligent urban system or service.
Assignment Brief
The central assignment of this course is a semester-long project in which students, working individually or in pairs, design and develop a smart city system, smart urban service, or intelligent urban application that addresses a real or plausible urban problem. The project is developed progressively over thirteen weeks through guided workshop activities, culminating in a final presentation with an accompanying demonstrator, proof of concept, or workflow prototype.
Projects may operate at any urban scale, including a building, campus, district, neighbourhood, infrastructure network, city-wide service platform, or service ecosystem. There is no single required topic: students may focus on transport, environment, building management, public health, energy, water, mobility, safety, waste, civic services, or any other domain where data, digital infrastructure, and AI workflows can create meaningful urban value. The project should engage with a specific, clearly defined context rather than proposing a generic or notional smart city vision.
Each project must address the following elements, developed progressively over the course of the semester:
Problem definition: A clearly stated urban problem, opportunity, or service gap, with identified users and affected stakeholders.
-- System logic: An explanation of how the proposed system works, including its components, data flows, decision points, and outputs. Students must articulate what makes their system "smart" — how it senses, coordinates, predicts, adapts, or delivers value.
-- Data and information model: Identification of relevant data sources, including open government datasets, APIs, sensor data, and/or BIM-based information models. Students should explain how data is accessed, structured, and used within the system.
-- Digital twin or BIM relation: Where relevant, students should show how their system connects to building or urban information models, and how digital twin logic — monitoring, feedback, updating, and coordination — applies to their project.
-- AI and workflow logic: Students should demonstrate how AI tools, agents, scripts, APIs, or no-code/low-code platforms are used to support the system. This may include AI-assisted data querying, decision support, retrieval-augmented workflows, automated responses, or intelligent service logic.
-- Interface or interaction logic: A description or mock-up of how users interact with the system, whether through a dashboard, application, API response, alert system, or other interface.
-- Implementation value: A clear account of who benefits, why the system is useful, and whether it creates public, institutional, or commercial value. Students should consider feasibility and implementation context.
-- Students may develop their projects by building on the shared course repository of datasets, APIs, scripts, notebooks, workflows, BIM and digital twin references, and AI workflow examples — or by developing project-specific resources of their own. Both approaches are equally valid; what matters is that students can explain and defend their technical choices.
The final output should not be a vague conceptual vision. It should be a clearly defined system proposal with a coherent prototype, workflow demonstration, application mock-up, or proof of concept appropriate to the project's scope and ambition. The project is assessed through a midterm presentation, a final presentation with demonstrator, and an individual reflection.
Assessment and Grading
Assessment Structure
Items
%
Class and Workshop Participation
Assessed on the basis of attendance, active engagement in workshop activities, contribution to class discussions, peer interaction, and demonstrated week-on-week progress on the project.
-- Midterm Presentation
10%
Midterm Presentation
A structured PowerPoint presentation introducing the student's project idea, urban problem statement, target users and stakeholders, preliminary system logic, identified data sources, and initial technical approach. To be delivered in Week 9.
20%
Final Presentation with Demo / Proof of Concept
A final PowerPoint presentation accompanied by a demonstrator, proof of concept, workflow prototype, application mock-up, smart service logic, or other appropriate project-specific output. The presentation must clearly explain the urban problem, system architecture, data stack, AI or digital workflow, user-facing interface logic, and implementation value. To be delivered in Week 13.
50%
Final Reflection Paper
An individual written submission of approximately 1,000–1,500 words in which the student reflects critically on the development of their project. The reflection should describe how the student approached the problem, how they selected and used datasets, APIs, tools, AI workflows, and/or code; what they learned; what they would do differently; and how the project might be developed further. The reflection is submitted individually regardless of whether the project was developed in a pair.
20%
Assessment Methods
Items
Concepts
Assessment Methods
1) Midterm and Final Presentations; Final Reflection
-- Identify and frame an urban problem addressable through a smart system
-- Workshop activities; peer discussion; project development
-- Midterm Presentation; Final Presentation
Analyse how data, platforms, APIs, sensors, and AI can be combined into an intelligent urban system
-- Analyse how data, platforms, APIs, sensors, and AI can be combined into an intelligent urban system
-- Workshops; case studies; technical exploration sessions
Final Presentation with Demo / POC
2) Develop a smart city prototype, application, or proof of concept using data, tools, code, and AI-assisted workflows
-- Guided workshops; iterative project development; peer reviews
Final Presentation with Demo / POC; Final Reflection
Teaching and Learning Method
Learning in this course is grounded in the principle of learning by making. Students are not expected to resolve every technical challenge independently; rather, they are encouraged to use available tools — including AI, no-code platforms, open APIs, and shared course resources — to make progress and to develop their critical judgement about the tools they use. The course places particular emphasis on student agency: students choose their own project, define their own problem, and select their own technical approach, with guidance from the instructor and teaching assistants.
Indicative Mode Distribution
Lectures and conceptual presentations: approximately 30%
Guided workshops and applied tutorials: approximately 50%
Student presentations and peer reviews: approximately 20%
Local Visits
Optional local visits may be arranged to expose students to smart city platforms, digital infrastructure, and innovation environments in Hong Kong. Details will be announced during the term.
Schedule
Week
Topic
Description
1) 1
Introduction: What Makes a City Smart?
Lecture: Smart cities as systems — definitions, examples, and the logic of urban intelligence. Introduction to the course structure, semester project, workshop format, and shared course commons. Discussion: what does "smart" actually mean?
Workshop: Students identify an urban problem or opportunity that interests them and begin to describe it in system terms: what is happening, who is affected, what data might exist, what a smart response might look like.
2) 2
Smart City Domains and Urban Problem Framing
Lecture: Survey of smart city domains — transport, environment, energy, buildings, public services, civic infrastructure. How cities collect, process, and use data to govern urban systems. Introduction to the Hong Kong Smart City Blueprint 2.0 and related local context.
Workshop: Students define their project issue, target user group, and urban context. First structured project brief submitted for instructor feedback.
3) 3
BIM Fundamentals and Information-Rich Urban Systems
Lecture: Introduction to Building Information Modelling — history, LOD (Levels of Development / Detail), lifecycle applications in architecture, construction management, site supervision, and facility management. How BIM relates to smart city data infrastructure. Introduction to the BIM software ecosystem.
Workshop: Students translate their project idea into an information structure — what objects, spaces, or systems need to be modelled or described? What information is needed and when?
4
From BIM to Digital Twin
Lecture: The logic of digital twins — moving from static representation toward live monitoring, feedback loops, operational management, and system intelligence. Examples of building-scale, district-scale, and city-scale digital twins. How digital twins integrate BIM with real-time sensor data and AI.
Workshop: Students develop a first system diagram for their project — mapping components, data flows, feedback loops, and outputs. What would a digital twin of their system look like?
5
Open Data, APIs, and Urban Platforms
Lecture: Introduction to open urban data, government datasets, APIs, and platform ecosystems. How smart city systems are built by connecting existing data and platforms rather than inventing new ones. Survey of available Hong Kong resources: Development Bureau data, Buildings Department records, Lands Department Location Search API, Transport Department parking data, Environmental Protection Department air quality data, and others.
Workshop: Students identify the data sources and platform connections relevant to their project. They access at least one open API or dataset and document how it works.
6
Urban Data Workflows and System Architecture
Lecture: How to design a data workflow — inputs, processing, outputs, storage, triggers, and user-facing responses. Introduction to system architecture diagrams and workflow logic for urban applications. Examples of real-world smart city data pipelines.
Workshop: Students map the complete workflow of their project — from data input to system output. They produce a structured system architecture diagram and workflow description.
7
IoT, Sensing, and Urban Monitoring
Lecture: Introduction to the Internet of Things — devices, sensors, connected hardware, and real-time data generation. How IoT enables urban monitoring: air quality, traffic, noise, occupancy, energy, water. How sensing connects to service activation and value creation.
Workshop: Students identify the sensing logic for their project — what would need to be sensed or measured? What devices, platforms, or proxies could provide that data? Students integrate sensing logic into their system diagram.
8
AI Agents, RAG, and Workflow Design
Lecture: Introduction to AI agents, retrieval-augmented generation (RAG), and AI-assisted workflow design. How AI can support data querying, decision support, automated responses, and smart service logic. AI as a systems-building tool, not only a writing assistant. Introduction to no-code and low-code AI workflow platforms.
Workshop: Students test AI-supported system logic for their project — using AI tools to query data, generate or refine workflow scripts, prototype interface logic, or build a simple AI-assisted decision layer.
9
Midterm Presentation
Students deliver a structured midterm presentation covering: urban problem statement; target users and stakeholders; system logic and preliminary architecture; data sources and platform approach; technical direction and tools selected. Feedback provided by instructors and peers. No workshop activity this week; the full session is dedicated to presentations and structured feedback.
10
Interfaces, Dashboards, Applications, and User Experience
Lecture: Introduction to interface design for urban systems — dashboards, data visualisations, alert systems, public-facing applications, and API-driven services. Principles of user experience for civic and institutional smart city tools. Examples of effective and ineffective smart city interfaces.
Workshop: Students develop the user-facing logic of their project — designing or sketching an interface, dashboard, or interaction model. Students begin moving toward a prototype or proof of concept.
11
Social Innovation, Entrepreneurship, and Value Creation
Lecture: What makes a smart city system meaningfully useful? Discussion of public value, institutional value, and commercial value. Introduction to social innovation and urban entrepreneurship as frameworks for evaluating and communicating smart city proposals. Why "smart" systems fail — and how to avoid common traps.
Workshop: Students develop their implementation logic — who would deploy this system, who would fund it, who would use it, and what value would it create? Students refine the value proposition section of their project.
12
Prototype Development and Project Integration
Lecture: Brief review of prototype strategies — what counts as a proof of concept, a demonstrator, a workflow mock-up, or a minimum viable system? How to present and defend technical choices.
Workshop: Students consolidate all components of their project — data, workflows, interface logic, BIM or digital twin connection, AI integration, and implementation narrative — into a coherent final presentation and demonstrator. Instructor and TA desk reviews conducted for all projects.
13
Final Presentation with Demo / Proof of Concept
Students deliver their final presentations, each accompanied by a demonstrator, proof of concept, workflow prototype, application mock-up, or other appropriate project output. Presentations are assessed by the course instructors and, where possible, invited reviewers from industry or government. Each team presents for approximately 12–15 minutes followed by questions.
Declaration to the assignment and penalty for academic dishonesty are attached in Appendices VI and VII.
Penalty for late submission
Failure to submit the assignments without justification before the submission deadline will be subject to the following penalties:
Within 24 hours after the deadline
One sub-grade of the assignment will be deducted
Within one week after the deadline
A bare passing grade (D) will be given to the assignment
Beyond one week after the deadline
A failing grade (F) will be given to the assignment
Feedback for Evaluation
Feedback for Teachers etc.
To whom
Where
When
Qualitative feedback from students/discussion forums
Tutors and/or teacher through informal interaction
Inside/outside classroom
Throughout the term
Mid-term and end of term course evaluation
Teacher and department
Lecture room
1 month into term and end of the term
Reflection of teacher (incl. evidence from assessment)
Teacher and tutors
All learning activities
Throughout the term
Curriculum review
Related teacher and Programme Committee
CUHK
Periodically
Visiting Committee
University, department and teacher
Feedback for Students
To whom
Where
When
Verbal feedback
Students
Inside/outside classroom
Throughout the term
E-discussion forum
Students
E-platform
Feedback sheets on project reports and essays
Students
Email/teacher’s office
After marking
Contact details for professor and TA
Professor
Professor
Name
Dr. Tat Lam
Office Location
School of Architecture
Telephone
68007447
Email
tatlam@cuhk.edu.hk
Teaching Assistant
Teaching Assistant
Name
Office Location
Telephone
Email
Required Readings and Resources
Selected readings, datasets, and technical resources will be provided on the course platform at the start of term. Students are not required to purchase any textbook. The following areas will be covered through curated readings, reference guides, and workshop materials:
-- Smart city systems and urban intelligence — selected policy documents, academic surveys, and case studies, including the Hong Kong Smart City Blueprint 2.0 and international comparators.
-- BIM and digital twin — introductory technical guides, BIM standards references, and digital twin precedent studies appropriate for undergraduate level.
-- Open data, APIs, and urban platforms — selected government open data portals, API documentation, and platform introductions relevant to Hong Kong urban systems.
AI and workflow tools — curated references on AI agents, retrieval-augmented generation, no-code and low-code platforms, and AI-assisted urban data analysis.
Social innovation and value creation — selected readings on smart city social impact, entrepreneurship, and public-private partnerships in urban technology.
-- A shared course commons — including curated datasets, open APIs, sample scripts, notebooks, workflow templates, BIM and digital twin reference examples, and AI workflow demonstrations — will be made available to all students. Students may also source, develop, and use their own materials.
AI Policy
The use of AI tools is encouraged in this course, subject to explicit acknowledgement and responsible practice. Students may use AI tools — including large language models, code-generation tools, AI workflow platforms, and AI agents — for research, coding assistance, prototyping, workflow design, data analysis, interface drafting, and the construction of smart city systems and services. AI is understood in this course as a substantive component of the smart city toolkit, not merely a writing aid.
Appropriate uses of AI in this course include: supporting research and literature review; generating, debugging, or refining code and scripts; building AI agents or retrieval-augmented workflows; querying and analysing datasets; prototyping interface logic or design mock-ups; developing smart service logic; and constructing automated or decision-support workflows. AI should be treated as a systems-development and prototyping tool, not merely as a text editor.
Students are reminded that the use of AI tools does not reduce the standard of critical thinking, accuracy, and intellectual responsibility expected of them. AI-generated text, code, diagrams, or visual outputs must not be submitted uncritically or without review. Students must be able to explain and defend any AI-assisted output in their presentations and reflections. Where AI is used substantially in any component of the project, students should document how it was used and reflect on both its value and its limitations. Failure to acknowledge AI use where it has materially contributed to submitted work is considered a form of academic dishonesty.
Academic Honesty and Plagiarism
Attention is drawn to University policy and regulations on honesty in academic work, and to the disciplinary guidelines and procedures applicable to breaches of such policy and regulations. Details may be found at http://www.cuhk.edu.hk/policy/academichonesty/. AI is allowed, but you must acknowledge your source with proper citation and the way you use which AI tool you used and for which part of your assignment (see Appendix II).
With each assignment, students will be required to submit a signed declaration that they are aware of these policies, regulations, guidelines and procedures.
-- In the case of group projects, all students of the same group should be asked to sign the declaration, each of whom is responsible and liable to disciplinary actions should there be any plagiarized contents in the group project, irrespective of whether he/she has signed the declaration and whether he/she has contributed directly or indirectly to the plagiarized contents.
-- For assignments in the form of a computer-generated document that is principally text-based and submitted via VeriGuide, the statement, in the form of a receipt, will be issued by the system upon students’ uploading of the soft copy of the assignment.
Assignments without the properly signed declaration will not be graded by teachers.
Only the final version of the assignment should be submitted via VeriGuide.
The submission of a piece of work, or a part of a piece of work, for more than one purpose (e.g. to satisfy the requirements in two different courses) without declaration to this effect shall be regarded as having committed undeclared multiple submission. It is common and acceptable to reuse a turn of phrase or a sentence or two from one’s own work; but wholesale reuse is problematic. In any case, agreement from the course teacher(s) concerned should be obtained prior to the submission of the piece of work.
Appendix I: Teaching Modes for Courses in Taught Programmes at CUHK
1) On-site face-to-face
-- The default teaching mode for all courses.
-- Students attend on-site face-to-face classes conducted by teachers.
-- A one-unit course represents one on-site face-to-face classroom contact hour per week.
-- The course can be supported by use of online Learning Management Systems or platforms for the purpose of uploading of course materials or assignment/assessment submissions.
-- It includes flipped classroom i.e., delivering a part of the course content and instruction via digital or online media, thus leaving more time for interactive activities in class, with no reduction in on-site face-to-face contact hours.
-- If assessment in the form of examination is to be adopted, it should be conducted on-site with invigilation.
2) Online synchronous (or online face-to-face/remote face-to-face)
-- In general, the arrangements are the same as on-site face-to-face mode, except that classes are conducted using video-conferencing tools like “Zoom” (the delivery mode adopted in Term 2 of 2019-20).
-- A one-unit course represents one online face-to-face contact hour per week.
-- It includes flipped classroom in which there is no reduction in online face-to-face contact hours.
-- Video-taping of lectures should not be counted as face-to-face contact hours.
-- If assessment in the form of examination is to be adopted, on-site examination with invigilation is preferred, except under very special circumstances.
3) Online asynchronous (or online course)
-- All course materials will be posted online. The on-site or online face-to-face contact hour is replaced by video lectures or series of micro-modules.
-- In general, there is no interaction between teachers and students.
-- There could be reduction of contact hours, but students’ total learning hours (e.g. assigned readings) remain to be 117 – 146 hours for a 3-unit course.
-- To enhance students’ learning, there should be online synchronous or on-site face-to-face tutorials as far as practicable.
-- If assessment in the form of examination is to be adopted, on-site examination with invigilation is preferred, except under very special circumstances.
4) Mixed mode (teaching modes 1 + 2)
-- In view of physical constraints, e.g., quarantine arrangement under the pandemic, or overseas internship courses, arrangement can be made so that some students attend on-site face-to-face lecture, while the other students of the same class attend online face-to-face lecture.
-- There is no reduction on the on-site or online face-to-face contact hours.
-- If assessment in the form of examination is to be adopted, on-site examination with invigilation is preferred, except under very special circumstances.
5) Blended mode (teaching modes 1 + 3, or 2 + 3)
-- It refers to a combination of on-site face-to-face and online asynchronous teaching modes, or online synchronous and online asynchronous teaching modes.
-- There could be not more than 75% reduction in on-site or online face-to-face contact hours. Otherwise, the course should be classified as an online asynchronous course.
-- Students’ total learning hours (e.g. assigned readings) should remain to be 117 – 146 hours for a 3-unit course.
-- If assessment in the form of examination is to be adopted, on-site examination with invigilation is preferred, except under very special circumstances.
6) Hybrid mode (teaching modes 1 + 2 + 3)
-- A combination of on-site face-to-face, online synchronous and online asynchronous teaching modes.
-- There could be reduction of contact hours, but students’ total learning hours (e.g. assigned readings) remain to be 117 – 146 hours for a 3-unit course.
-- If assessment in the form of examination is to be adopted, on-site examination with invigilation is preferred, except under very special circumstances.
Appendix II: Use of AI tools is allowed with explicit acknowledgement and proper citation
Students may use some AI tools in some class activities and assignments on the condition that they make explicit acknowledgement and proper citations of the input from AI tools.
Acknowledging support from AI tools
Students are required to acknowledge all functional uses of a generative AI tool and cite it when they paraphrase, quote, or incorporate into their own work any content (whether it is text, image, data, or other format) that was created by it.
An example of acknowledgement
‘I acknowledge the use of (name of AI tool – e.g. ChatGPT (https://chat.openai.com/) to (specify the support, e.g. plan my essay, generate some ideas for the content, ask for examples of data collection instruments, get the dates of historical events, etc.).
An example of citation
OpenAI. (2023). ChatGPT (Mar 20 version). https://chat.openai.com/chat
(Students are reminded that due to the rapid developments of generative AI tools, some citation formats may be updated regularly.)
An example of including texts generated by an AI tool in their work
"The following text was generated by an AI tool / language model (ChatGPT):"
[Insert the text generated by ChatGPT here.]
An example of including texts generated by an AI tool and the prompts that were used to elicit the text from the AI tool
"[The prompt], as generated by an AI language model (ChatGPT):"
[Insert the text generated by ChatGPT in response to the prompt.]
Students are reminded to learn and use the AI tools responsibly and ethically and be aware of the limitations. Students are reminded to clarify with the course teacher and obtain permission if necessary when in doubt.
Appendix III: Grade Descriptors for Course Assessments (Midterm Presentation, Final Presentation, Final Reflection)
A
B
C
D
F (Fail)
Content
Smart City Problem and System Definition
Urban problem is clearly and precisely defined; system logic is original, coherent, and well-justified; all required project elements (problem, users, data, workflow, AI/digital logic, value) are fully articulated with insight and depth
Urban problem and system logic are clearly stated and reasonably well-developed; most required elements are present; some aspects could be more precisely defined or developed
Urban problem is identified but system logic is vague or incomplete; required elements are partially addressed; proposal feels more like a concept than a system
Urban problem or system logic is unclear, underdeveloped, or generic; required elements are largely missing or superficially addressed
No clear urban problem or system logic; no meaningful engagement with required project elements
Integration of Technical and Urban Components
BIM, data, APIs, IoT, digital twin logic, and/or AI workflows are meaningfully and appropriately integrated into the system; choices are well-justified and clearly connected to the urban problem
Technical components are present and mostly appropriate; integration is generally coherent, though some connections could be more explicitly justified
Some technical components are mentioned but not meaningfully integrated; the connection between tools and the urban problem is weak or unclear
Technical components are largely absent, inappropriate, or named without explanation; little evidence of meaningful engagement with BIM, data, APIs, or AI
No meaningful use of any relevant technical component; proposal is purely conceptual or generic
Prototype / Proof of Concept / Demonstrator Quality
Prototype, proof of concept, or demonstrator is substantive, clearly functional or operable, and directly supports the project argument; demonstrates real technical engagement and ambition
Prototype or proof of concept is present and meaningful; demonstrates genuine technical effort, though scope or depth could be developed further
Prototype or proof of concept is minimal or partial; some technical output is visible but it does not fully demonstrate the proposed system
Prototype or proof of concept is largely absent or tokenistic; little or no demonstrable technical output
No prototype, proof of concept, or demonstrator; project remains entirely conceptual
Implementation Logic and Value Proposition
Implementation logic is clearly and convincingly articulated; the value proposition — who benefits, why the system is useful, and how it could be deployed — is original, specific, and well-argued
Implementation logic and value proposition are present and generally convincing; some aspects of feasibility or benefit could be more precisely articulated
Implementation logic is present but vague or optimistic; the value proposition is acknowledged but not well-developed or specifically argued
Implementation logic is weak or absent; value proposition is generic, speculative, or unconvincing.
No consideration of implementation or value; proposal is not connected to any plausible real-world deployment
Presentation
Presentation
Clarity and Quality of Presentation
Presentation is exceptionally well-structured, visually clear, and logically sequenced; arguments flow compellingly; slides and diagrams are professionally designed and directly support the project narrative
Presentation is well-structured and clear; good logical flow; slides are adequately designed and support the argument, with minor lapses in clarity or visual quality
Presentation is adequately structured but uneven; some sections are unclear or poorly sequenced; slides do not consistently support the argument
Presentation is poorly structured or difficult to follow; slides are unclear, cluttered, or inconsistent with the spoken argument
No evident structure; presentation is incoherent, underprepared, or fails to communicate the project
Source Acknowledgement (Data, Tools, AI, References)
All data sources, APIs, tools, AI uses, and references are consistently and properly acknowledged; AI contributions are clearly and transparently disclosed
Most sources and tools are acknowledged; AI use is disclosed; some references or acknowledgements are incomplete
Acknowledgement of sources and tools is inconsistent; AI use may not be fully disclosed; some data sources or references are unnamed or improperly cited.
No acknowledgement of any kind; potential academic integrity concern
No acknowledgement of any kind; serious academic integrity concern.
English writing
English writing
Spelling
No spelling mistakes
Few spelling mistakes
Quite a few spelling mistakes
Clear evidence of not using spell check
Many spelling mistakes
Grammar
Few, if any, grammatical mistakes
Grammatical mistakes can be found, often due to weak English foundation.
Quite a few grammatical mistakes. Writing style difficult to follow
Writing is largely unintelligible due to pervasive grammatical errors
Full of grammatical mistakes; largely unintelligible.
Writing style
Clear and effective writing style that facilitates understanding & communication
Generally clear and effective writing style that serve to communicate
Writing style that fails to communicate effectively
Poor writing style that fails to articulate a particular point of view; writing style impedes understanding.
Poor readability
Appendix IV: Peer Assessment Form
To ensure student’s contribution is adequately reflected in project work, students are required to assess each of your group members on their respective contributions. Assessment should be based on (1) Participation and Team Work; (2) Timely Input and Punctuality; (3) Leadership; and (4) Knowledge, Innovative Ideas and Quality of Work throughout class and group discussions within and outside classroom. Marks should be given between 0-10, 10 being full mark as the best performance. The overall contribution is based on 40 marks. The result will be used as a factor to adjust the overall grade of individual students. PLEASE NOTE THAT THE ASSESSMENT SHOULD BE DONE INDIVIDUALLY AND THE ASSESSMENTS WILL BE KEPT HIGHLY CONFIDENTIAL. AND YOU ARE NOT SUPPOSED TO ASSESS YOURSELF.
Assessment and Comments (please use marks ranging from 0-10, 10 being the best performance):
Name
P & TW
TI & P
L
K, II & QoW
Overall Contribution
Comments* (strengths & weaknesses)
Notes:
P & TW: Participation and Team Work;
TI & P: Timely Input and Punctuality;
L: Leadership;
K, II & QoW: Knowledge, Innovative Ideas and Quality of Work
*Please use additional sheet if required
Name of Assessor: Signature:
Date:
Appendix V: Grade Descriptor for the Final Project (Final Presentation with Demo / POC and Final Reflection)
A
B
C
D
F (Fail)
Content
Project Definition and System Logic
-- Urban problem is precisely and compellingly defined; system logic is original, comprehensive, and fully coherent; all required project components are thoroughly and insightfully articulated
--
-- Urban problem and system logic are clearly stated and adequately developed; most required components are present and reasonably well-argued
--
-- Urban problem is identified but system logic is incomplete or underdeveloped; required components are only partially addressed; the project reads more as a concept than a coherent system
--
-- Urban problem or system logic is unclear, generic, or poorly developed; required components are largely missing or superficially engaged
--
-- No coherent urban problem definition or system logic; project fails to engage meaningfully with required components
Technical and Data Integration
BIM, data sources, APIs, IoT, digital twin logic, and/or AI workflows are meaningfully, appropriately, and creatively integrated; technical choices are clearly justified and directly support the urban problem
Able to interpret and apply technical components with good insight; integration is mostly coherent and appropriate with minor gaps in justification
Shows some understanding of relevant technical components; integration is present but uneven, with some connections between tools and problem remaining unclear
Technical components are mentioned but not meaningfully applied; little evidence of genuine engagement with data, APIs, or AI workflows
No meaningful technical or data integration; proposal is entirely conceptual without demonstrated use of any relevant tools or sources
Prototype / Proof of Concept / Demonstrator
Prototype, proof of concept, or demonstrator is substantive, clearly functional, and directly demonstrates the proposed system; reflects real technical ambition and skill
Prototype or proof of concept is present and meaningful; demonstrates genuine technical effort; scope or depth could be further developed
Prototype or proof of concept is minimal; some technical output is visible but insufficient to fully demonstrate the proposed system
Prototype or proof of concept is largely absent or tokenistic; little or no functional demonstrable output
No prototype or demonstrator; project remains entirely conceptual
Reflection and Critical Evaluation (Final Reflection)
Reflection is incisive, honest, and detailed; development of the project is clearly narrated; use of tools, AI, and data is transparently and critically evaluated; future development is thoughtfully considered
Reflection is clear and substantive; project development is adequately described; use of tools and AI is acknowledged and discussed with reasonable depth
Reflection is present but somewhat superficial; development narrative is incomplete; critical evaluation of tools and AI use is limited
Reflection is minimal or largely descriptive; little critical evaluation of project development, tools, or AI use
No meaningful reflection; submission is absent, perfunctory, or entirely uncritical
Implementation Logic and Value Proposition
-- Implementation logic is convincing, specific, and clearly reasoned; value proposition — who benefits, how, and why the system is useful — is original, compelling, and grounded in realistic assessment
-- Implementation logic and value proposition are articulated and reasonably convincing; feasibility is generally addressed with some gaps
Implementation logic and value proposition are present and adequately reasoned; most aspects of feasibility and benefit are addressed, though some may be underdeveloped.
Implementation logic is present but vague or optimistic; value proposition is acknowledged but not sufficiently developed or evidenced.
Implementation logic is weak or absent; value proposition is generic, speculative, or unconvincing.
No consideration of implementation or value; proposal has no credible real-world grounding.
Presentation
Presentation
Clarity and Professionalism of Presentation
Presentation and written reflection are done to a professional standard; slides, diagrams, and system architecture visuals are clearly numbered, well-designed, and effectively support the project argument
Presentation and reflection are clearly done; diagrams and figures are in order and support the argument; minor lapses in design or visual clarity
Presentation is adequately produced but uneven; some diagrams or figures are unclear or not properly integrated; written reflection is adequately structured
Presentation has significant weaknesses in structure or design; figures and diagrams are confusing or missing; written reflection is poorly organized
Presentation is poorly done; no meaningful visual support; written reflection is absent or incoherent
Presentation is unprepared, incoherent, or fails to communicate the project in any meaningful way.
Acknowledgement of Sources, Data, and AI Use
All data sources, APIs, tools, scripts, AI uses, and external references are consistently and properly acknowledged; AI contributions are clearly and transparently disclosed throughout
Most sources and tools are acknowledged; AI use is disclosed; some references or acknowledgements are incomplete or inconsistently formatted
Acknowledgement of sources and AI use is inconsistent; some tools or data sources are unnamed or improperly credited
Acknowledgement is largely absent; data sources, tools, and AI contributions are not disclosed or are improperly credited; plagiarism risk
No acknowledgement of any sources, tools, or AI; serious academic integrity concern
English writing
English writing
Spelling
No spelling mistakes
Few spelling mistakes
Quite a few spelling mistakes
Clear evidence of not using spell check
Many spelling mistakes
Grammar
Few, if any, grammatical mistakes
Grammatical mistakes can be found, often due to weak English foundation
Quite a few grammatical mistakes. Writing style difficult to follow
Writing is largely unintelligible due to pervasive grammatical errors
Full of grammatical mistakes; largely unintelligible.
Writing style
Clear and effective writing style that facilitates understanding and communication
Generally clear and effective writing style that serve to communicate
Writing style that fails to communicate effectively
Poor writing style that fails to articulate a particular point of view; writing style impedes understanding.
Poor readability
Appendix VI: Declaration to be attached to assignments
Assignments without the properly signed declaration will not be graded by teachers. Only the final version of assignment should be submitted via VeriGuide.
I am submitting the assignment for:
□ an individual project or
□ a group project on behalf of all members of the group. It is hereby confirmed that the submission is authorized by all members of the group, and all members of the group are required to sign this declaration.
I/We declare that: (i) the assignment here submitted is original except for source material explicitly acknowledged; (ii) the piece of work, or a part of the piece of work has not been submitted for more than one purpose (e.g. to satisfy the requirements in two different courses) without declaration; and (iii) the submitted soft copy with details listed in the is identical to the hard copy(ies), if any, which has(have) been / is(are) going to be submitted.
I/We also acknowledge that I am/we are aware of University policy and regulations on honesty in academic work, and of the disciplinary guidelines and procedures applicable to breaches of such policy and regulations, as contained in the University website http://www.cuhk.edu.hk/policy/academichonesty/.
In the case of a group project, we are aware that each student is responsible and liable to disciplinary actions should there be any plagiarized contents/undeclared multiple submission in the group project, irrespective of whether he/she has signed the declaration and whether he/she has contributed directly or indirectly to the problematic contents.
It is also understood that assignments without a properly signed declaration by the student concerned and in the case of a group project, by all members of the group concerned, will not be graded by the teacher(s).
__________________________ __________________________
Signature(s) Date
__________________________ __________________________
Name(s) Student ID(s)
_________________________ __________________________
Course code Course title
Appendix VII: Penalty for academic dishonesty
Case of Academic Dishonesty
Minimum Penalties
Plagiarism
First offence
(i) one demerit (shown on transcript);
(ii) a mark of zero for that component of the course; and
(iii) completion of relevant training in academic honesty.
Second or further offence (and a first offence that is serious as decided by the disciplinary committee concerned/the FTP Committee)
(i) two demerits (of which one will remain in the University’s record permanently and one is reviewable); and
(ii) a failure grade for the course concerned.
Undeclared Multiple Submission / Self-plagiarism
Plagiarism in Group Project
All group members are responsible and liable irrespective of whether one has contributed directly/indirectly to the problematic contents.
Distribution/ Sharing/ Copying of teaching materials without teacher’s consent to gain unfair academic advantage in the courses
Two demerits
Undertake the examinations/ final year projects/ papers/ essays/ dissertations via the following means:
a) employing or using services provided by a third party;
b) providing services as a third party;
c) sharing of any materials obtained from the employment or use of services provided by a third party to other students; and
d) knowingly using materials obtained by anyone who has employed or used the services provided by a third party.
(i) three demerits (of which one will remain in the University’s record permanently and two are reviewable);
(ii) a failure grade for the course concerned (not applicable to the student who sells the papers/essays/dissertations);
(iii) suspension from the University for one term [Note 1]; and
(iv) lowering the degree classification by one level upon graduation (not applicable to undergraduate students who graduate with a Pass Degree, MBChB students and postgraduate students) [Note 2].
[Note: A third party shall include all parties external to CUHK, including but not limited to online platforms, companies providing tutoring services or essay/ dissertation mills, private tutors, past teachers, alumni of the University, relatives and friends of the student concerned, as well as members of CUHK.]
Violating rules 15 or 16 of the University’s Rules to be Observed by Candidates at Examination Centre
Exam: start reading/ writing/ typing without permission; continue to write/type after “pens‐down” announcement
First offence
(i) one demerit.
Second or further offence (and a first offence that is serious as decided by the disciplinary committee concerned/the FTP Committee)
(i) two demerits (of which one will remain in the University’s record permanently and one is reviewable).
Cheating in tests and
examinations (including violation of rules 17 or 18 of the University’s Rules to be Observed by Candidates at Examination Centre)
During Exam/Online exam:
‐ Carry unauthorized materials or place unauthorized materials on examination desk/nearby furniture
‐ Communicate or attempt to communicate with other candidates
‐ Copy from unauthorized materials/work of another candidate
‐ Attempt to use electronic devices with transmission/ photo‐taking/data storage functions
First offence
(i) One demerit (which will remain in the University’s record permanently); and
(ii) a failure grade for the course concerned.
Second or further offence (and a first offence that is serious as decided by the disciplinary committee concerned/the FTP Committee)
(i) two demerits (of which one will remain in the University’s record permanently and one is reviewable); and
(ii) a failure grade for the course concerned.
Impersonation fraud in tests and examinations
(including violation of rule 19 of the University’s Rules to be Observed by Candidates at Examination Centre)
(i) three demerits (of which one will remain in the University’s record permanently and two are reviewable);
(ii) a failure grade for the course concerned;
(iii) suspension from the University for one term [Note 1]; and
(iv) lowering the degree classification by one level upon graduation (not applicable to undergraduate students who graduate with a Pass Degree, MBChB students and postgraduate students) [Note 2].
[The same penalties apply to the student who asks/allows someone to assume his/her identity to sit for a test/an examination as well as to the student who sits for a test/an examination if both parties are students of the University, except that penalty (ii) will not apply to the latter.]
Some unaware mistakes (examples of established offences) are listed below to facilitate students’ understanding.
Case of academic dishonesty
Examples of established offences
Plagiarism
1) Using online translator to translate texts and quoting the translated content without proper citation
2) Quoting references from Wikipedia without proper citations
3) In a group project, student A “thought” that s/he was not responsible for the plagiarized work written by student B.
4) Using / Quoting other students’ works or ideas without proper citation
5) Ideas in article A is paraphrased in article B. One copies words from B without proper citation to both primary source A and secondary source B.
Self-plagiarism
1) Submitting a part of a piece of work for more than one courses without declaration and proper citation
2) Submitting the same piece of work for two different courses without declaration and proper citation
Use 3rd Party Service
1) Posting exam questions on online platform
2) Obtaining answers provided by online platform
3) Sharing answers during online exams
Violate Exam Rules
1) Continue writing after “Pens-down” announcement
For details, please visit “Honesty in Academic Work: A Guide for Students and Teachers”.