One Toolchain, Six Domains: A Multiple-Case, Document-Based Study of Rapid IoT Prototypes Built in a One-Week Immersive Course on a Master’s Program in Applied Artificial Intelligence

Abstract

This paper reports a document-based, multiple-case study of six Internet of Things (IoT) prototypes designed and simulated during a one-week immersive course, “IoT for Data Intelligence,” delivered in July 2026 within the professional Master in Applied Artificial Intelligence (Maestría en Inteligencia Artificial Aplicada, MNA) at Tecnológico de Monterrey. Six teams followed the same five-day toolchain IoT theory; Oracle Application Express (APEX), SQL, and REST service design; MIT App Inventor; ESP32/Wokwi simulation; and generative AI integration and produced Wokwi-simulated prototypes spanning industrial energy monitoring, agricultural hazard response, residential automation, cardiovascular telemonitoring, industrial waste reduction, and precision agriculture. A fixed coding framework was applied across architecture, AI-integration pattern, platform-level failure modes, security debt, and Sustainable Development Goal alignment, distinguishing findings that the course structure itself prescribes from findings the teams introduced independently. The six cases converged on a shared five-layer architecture and, in a pattern only partly prescribed by the course, on keeping generative AI in an advisory or fail-safe-wrapped role. Deposited results were also compared, for illustrative purposes only, against the course’s internal competency rubric. An observed proposal from a Pontifical Catholic University of Chile collaboration is discussed as an informal reference point rather than as evidence for generalization. This paper discusses the implications and limits of this small, single-institution, single-cohort, simulation-only case set.

1. Introduction

Short, intensive IoT workshops increasingly ask small teams to take a complete system sensing, cloud persistence, a mobile client, and, increasingly, an AI layer from a blank canvas to a working, cloud-connected prototype in a matter of days. What such compressed pedagogy reliably produces at the architecture level, and where it reliably fails, is rarely documented across more than a single project. This paper addresses that gap using a naturally occurring, matched case set: six technical reports, independently authored by six small teams enrolled in the same one-week course, using the same low-cost toolchain, in the same July 2026 cohort of the Master in Applied Artificial Intelligence at Tecnológico de Monterrey with the participation of visiting students from the Pontifical Catholic University of Chile.

Because the six teams worked under the same instructor and the same five-day structure but chose their own application domain, sensor set, and depth of cloud integration, the resulting corpus allows two related but distinct questions to be asked. First, what does the course structure itself predictably produce, given that it prescribes a specific tool for each day? Second, on the narrower set of choices the course leaves open how AI is positioned relative to control decisions, how platform-level obstacles are handled, and how security trade-offs are resolved what do independently working teams converge on without being told to, and where do they struggle in the same way? This distinction between prescribed and team-initiated convergence is treated here as the paper’s central methodological safeguard rather than a secondary caveat.

The six teams’ reports are supplemented, as a deliberately non-generalizable reference point, by a parallel proposal contributed by a postgraduate student collaborator and visitor from the Pontifical Catholic University of Chile, using a different technology stack. This contrast case is discussed only descriptively (Section 3.2.7) and is explicitly excluded from every quantitative or generalization claim in this paper.

Related Work

Internet of Things curricula increasingly rely on browser-based circuit simulators rather than physical laboratory kits, both to remove hardware-access bottlenecks and to shorten iteration cycles; recent classroom studies of the Wokwi simulator report that it supports experiential, STEM-oriented learning in higher-education settings with limited laboratory infrastructure [1]. A broader systematic review of IoT curricula, pedagogy, and assessment across STEM education documents wide variation in how programs structure hands-on IoT instruction and calls for more empirical reporting on what such courses produce [2]. Within the specific toolchain used here, MIT App Inventor has been documented as a viable, low-code path for building mobile clients that collect and visualize microcontroller sensor data [3], and the integration of large language models with resource-constrained IoT clients has been characterized as facing latency, token-budget, and reliability constraints that push practical designs toward relay-mediated or advisory-only architectures [4] a pattern this paper’s cross-case analysis is consistent with, though it does not independently confirm it beyond the present cohort (Section 3.2.2). On the platform-friction side, TLS handshake overhead has been identified in the constrained industrial-IoT literature as a dominant bandwidth and processing cost for small clients, motivating mitigations such as handshake caching [5]; several of the cases analyzed here arrive at a structurally similar mitigation an external relay that performs the TLS-heavy request on unconstrained hardware independently and without reference to that literature.

Beyond the specific toolchain, the pedagogical format used here a single-week, team-based prototyping sprint culminating in a working system sits within a broader literature on time-bounded, event-style engineering education. A systematic review of hackathon-like learning events found that although such formats are widely used to promote applied learning, no standardized method has yet been established for eliciting or rigorously measuring the learning outcomes they produce [6], with most existing studies relying on self-reported rather than independently verified evidence [7]. This same tension between a compressed, high-intensity format and the difficulty of independently verifying what it produces motivates the prescribed-versus-team-initiated distinction adopted in Section 2.6 and is revisited as a limitation in Section 5. Separately, reviews of competency-based learning in engineering education have called for more explicit, reproducible evidentiary standards when mapping student deliverables onto institutional competency frameworks, noting that many existing frameworks specify what should be assessed without specifying what evidence should count as having met it [8]; this concern is directly relevant to the benchmarking exercise carried out in Section 3.3.

Methodologically, this paper follows the multiple-case study logic of Yin [9], in which cases produced under the same intervention are treated as literal replications whose convergent findings carry more evidential weight than any single case, and cases produced under a deliberately different intervention are treated as theoretical replications that test the boundary of a pattern. The six ITESM prototypes are framed, collectively, as naturalistic instantiations of an artifact in the design-science sense used in information-systems research [10]: the contribution is not any one instantiation, but what can be learned by evaluating the artifact across several of them, while acknowledging that the artifact’s own boundaries are set in part by the course that produced it.

2. Materials and Methods

2.1. Institutional and Pedagogical Context

All six case studies analyzed in this paper originate from the same course, “IoT for Data Intelligence,” delivered over one week in July 2026 as part of the professional Master in Applied Artificial Intelligence (MNA) offered by Tecnológico de Monterrey with the participation of visiting students from the Pontifical Catholic University of Chile. The course followed an identical five-day structure for every team:

• Day 1: Theoretical foundations of IoT architecture, history, and future directions.
• Day 2: database design with Oracle Application Express (APEX), SQL, RESTful web services (ORDS) 23.3, and dashboard development.
• Day 3: mobile solution design in MIT App Inventor 2 (AI2), integrated with the Oracle APEX database built on Day 2.
• Day 4: embedded simulation in Wokwi 2026, wiring representative sensors (e.g., DHT22, PIR/motion sensors, LEDs, potentiometers as sensor proxies) to an ESP32, and sending telemetry to Oracle APEX over REST using MicroPython v1.20 (or, in one case, Arduino/C++).
• Day 5: integration with a generative AI service (Gemini 3.8-flash, in most cases) for data interpretation and natural language reporting, with the course materials explicitly framing this integration as advisory rather than as an autonomous control layer.

Because Day 5 already frames generative AI as advisory before any team begins its own design work, this paper treats the advisory framing of AI as a partially prescribed starting point rather than a fully independent team discovery; Section 3.2.2 reports what each team did beyond that starting point.

Each team selected its own application domain and mapped it to at least one United Nations Sustainable Development Goal (SDG), then produced a full technical report documenting design, implementation, and a closing self-assessment against three standardized questions common to every report in the corpus: does the project generate value, is the client prepared for implementation, and is the team prepared to carry it out. This shared rubric, together with a shared requirement to discuss applicable IEEE/ISO IoT standards [11], gives the corpus a controlled, prescribed layer of convergence that is analyzed separately (Section 3.2.6) from the unprescribed, team-initiated convergence that is this paper’s main object of study.

2.2. Research Design

This study uses a document-based, multiple-case synthesis [9], framed as a design-science evaluation [10] of one artifact the reference architecture that the course’s five-day structure and its participating teams jointly produce across six naturalistic instantiations, following the case-study research guidance of [12]. No new data was collected from students or instruments; the case record consists entirely of the six teams’ own deposited technical manuscripts, treated as primary documentary sources.

The analytic pipeline proceeds in three stages: (1) collecting primary data from the six student technical reports alongside the Chilean contrast case; (2) executing a structured, three-step qualitative coding procedure across the fixed dimensions defined in Section 2.5; and (3) synthesizing architectural patterns and benchmarking results against the institutional competency framework, as shown in Figure 1.

2.3. Case Corpus

The corpus comprises the six technical reports listed in

Table 1. The six-case corpus: team size, application domain, declared SDG alignment, edge/cloud stack, how each case positions its generative AI layer relative to control decisions, and completion status. Completion status is reported explicitly because Cases 4 and 5 did not implement a full closed control loop within the one-week course; this distinction is carried through the tallies rather than folded into undifferentiated “6 of 6” counts.

#	Team Output	Team Size	Domain/SDG	Edge Stack	AI Role	Completion Status
1	Visible Consumption (industrial energy/temperature) [13]	4	Industrial IoT/SDG 12	ESP32 + Wokwi, Arduino/C++, Groq LLM relay	Advisory diagnostic text (25-token)	Full loop implemented
2	SPAI-EH (hail/heavy-rain crop protection) [14]	4	AgriTech/SDG 15, 2, 6, 13	ESP32 + Wokwi, MicroPython, Gemini	Secondary classifier, local fallback	Full loop implemented
3	Sustainable Residential Energy Use [15]	3	Smart home/SDG 11	ESP32 + Wokwi, Micropython, Flask + ngrok	Retrospective pattern report	Full loop implemented
4	IoT-Based Vital Sign Monitoring [16]	4	Digital health/SDG 3	ESP32 + Wokwi, MicroPython, TLS-fingerprint proxy	Proposed explanation layer (grounded, not yet implemented)	Data pipeline verified; control loop not implemented
5	Liquid Waste Reduction (fabric-softener mfg.) [17]	4	Industrial sustainability/SDG 12	ESP32 + Wokwi, MicroPython	Prompt-level test only (not integrated into architecture)	Data pipeline verified; full control loop not implemented
6	Agrosensor (smart agriculture edge-AI) [18]	3	AgriTech/SDG 2	ESP32 + Wokwi, MicroPython, Node.js relay	On-demand advisory, edge-first control	Full loop implemented

, all produced by student teams in the July 2026 MNA cohort and deposited on Zenodo. All six are included (complete-population sampling within the cohort); none were excluded post hoc. Table 1 also reports each team’s size, since team size is a plausible covariate for the project-management and innovation ratings discussed in Section 3.3 and could not be assessed in the original analysis.

2.4. Data Sources and the Contrast Case

Primary data consists of the full text, figures, database schemas, and firmware excerpts of the six Zenodo-deposited manuscripts (full citations in the References section).

The same cohort also included a presentation contributed by a postgraduate collaborator from Pontifical Catholic University of Chile, related here as an observation only, noticed by the authors, proposing a conceptually related but architecturally distinct system: a unified electricity/gas/water telemetry node with an earthquake early warning actuation layer, built on a Raspberry Pi and microcontroller pairing, MQTT, oneM2M, ISO/IEC 30141 [19], and DLMS/COSEM rather than the ESP32/Wokwi/Oracle APEX/App Inventor toolchain used by the six ITESM teams. At the collaborator’s request, this contribution is presented here in student anonymized form: its architecture and design logic are described in Section 3.2.7 for descriptive, comparative purposes only, without naming its author and without including it as a formally cited reference in this paper’s bibliography. It is referred to throughout simply as “the Chilean presentation.” Because it was not built or validated in Wokwi, is not deposited under a citable identifier, and could not be independently verified, it is excluded from the coded, cited corpus in Table 1 and from every quantitative convergence or generalization claim in Section 3; it is used exclusively as an illustrative discussion point noticed by the authors, not as evidence that the patterns found across the six cases are architectural rather than toolchain-specific. Any resemblance between the Chilean proposal and the six-case pattern is reported descriptively and should not be read as a validated boundary test.

2.5. Coding Framework

Each of the six manuscripts was coded against a fixed set of dimensions, derived deductively from structural elements common to every report: architecture layers and technology choices; sensors and actuators used; the cloud/backend integration pattern, including any relay or proxy introduced to work around platform limits; where and how generative AI is positioned relative to control decisions; documented failure modes and how each team diagnosed them; security gaps the team itself acknowledged; declared SDG alignment; and the team’s answers to the standardized value/client-readiness/team-readiness rubric.

Table 2. Cross-case coding matrix across the six literal-replication cases (Section 2.5 and Section 2.6), with each dimension classified by convergence type.

Dimension	Finding Across the Six Cases	Cases Exhibiting It	Convergence Type
Sensing/edge platform	ESP32 simulated in Wokwi v0.26.1 as the sole hardware target; Micropython in 5/6 cases, Arduino/C++ in 1/6	6 of 6	Prescribed (toolchain)
Cloud persistence	Oracle APEX Release 26.1 schema exposed through ORDS, 3–5 related tables per case	6 of 6	Prescribed (toolchain)
Mobile client	MIT App Inventor v2.73+ consuming the ORDS layer; bidirectional write-back present in 4/6	6 of 6	Prescribed (toolchain)/team-initiated (write-back)
AI positioned outside the control-triggering step	Generative AI (model varies by case; see Table 1) used for advisory text or as a secondary, fail-safe-wrapped classifier; not yet implemented, but proposed as a future explanation layer, in one case (Case 4); tested only at prompt level and not yet wired into any architecture in one case (Case 5)	4 of 6 implemented as advisory; 1 of 6 (Case 4) proposed, not implemented; 1 of 6 (Case 5) prompt-tested only	Partially prescribed (Day 5 introduced Gemini as advisory)/partially team-initiated (extension to fail-safe wrapping and local-first logic)
Oracle APEX/ORDS platform friction	Independent workarounds for TLS/WAF/bot-mitigation limits: dedicated relay/proxy processes, inter-request spacing, or browser-TLS impersonation	4 of 6	Team-initiated
Self-reported credential exposure	Generative AI or backend API keys acknowledged as embedded in shareable simulator projects and requiring revocation/relocation	3 of 6	Team-initiated (self-disclosed)
Unauthenticated write endpoints	ORDS POST endpoints accepting inserts/commands without a device-level auth token; explicitly flagged as a pre-production gap in 2 of 6 reports and consistent with the default shared-workspace classroom configuration in the remainder	2 of 6 explicit; structurally present in the rest	Structural/not independently team-initiated
Prescribed convergence (rubric)	Every report closes with the same three-question course rubric (value generated/client readiness/team readiness)	6 of 6	Prescribed (rubric)
Prescribed convergence (standards)	Every report includes an appendix mapping the prototype to IEEE/ISO IoT standards [11]	6 of 6	Prescribed (rubric)

reports these as nine coded rows because the AI-integration and standards/rubric dimensions were each split into sub-rows during coding for clarity; the eight conceptual dimensions described above map onto the nine rows of Table 2 as documented in the table notes.

Coding was performed by the corresponding author, who also served as faculty advisor to all six teams, and reviewed for face validity by a co-author (J.R. Silva, University of São Paulo) who was not involved in the original coding pass. No formal inter-rater reliability statistics (e.g., Cohen’s kappa) were computed, and no independent, non-co-author reviewer was involved; this is reported here as a limitation (Section 5) rather than implied to be full inter-rater validation. Coded excerpts, decision rules, and disagreement notes from the two-reviewer pass are discussed during the study.

2.6. Analytic Procedure

• Within-case summary: each manuscript was first summarized independently against the coding dimensions above.
• Cross-case matrix: the six within-case summaries were assembled into a single case × dimensions matrix (Table 2) to make convergence and divergence directly inspectable.
• Pattern classification: for each dimension, the count of cases (out of six) exhibiting the same pattern is reported, together with an explicit classification of that dimension as course-prescribed, partially prescribed, or team-initiated (Table 2, rightmost column).
• Boundary discussion: for the two dimensions most central to this paper’s contribution, the five-layer architecture and the positioning of generative AI, the anonymized Chilean collaboration contrast case is discussed descriptively (Section 3.2.7) as an illustrative, non-generalizable comparison point.

2.7. Trustworthiness, Ethics, and Positionality

No new data were collected directly from human participants through surveys, interviews, or instruments; all analysis is secondary, document-based synthesis of already-authored, already-deposited technical reports, cited here under their Zenodo digital object identifiers (DOIs). However, this synthesis produces new, publicly identifiable evaluative claims about named student teams, including “Limited” competency ratings in the case-level competency matrix presented later in this paper (Section 3.3.3) because the six teams are identifiable from the cited Zenodo depositions and because the case numbers in Table 1 and Table 2, and in that later matrix, map directly onto those author names. This secondary evaluative use of identifiable student work is disclosed explicitly rather than treated as exempt by virtue of using only pre-existing documents.

The corresponding author’s dual role as faculty advisor to all six teams and as lead author of this synthesis is disclosed as a conflict of interest (Section “Conflicts of Interest”) and mitigated by relying exclusively on the teams’ own already-published, already-deposited claims, by having the coding reviewed by a co-author not involved in grading the six teams, and by inviting the six teams to review the case-level competency matrix (Section 3.3.3) prior to submission.

The Chilean contribution is described only in aggregate, anonymized form, consistent with the collaborator’s expressed preference and without attribution that would allow re-identification. All six Zenodo-deposited manuscripts remain the definitive technical record for their respective prototypes; this paper’s role is limited to cross-case synthesis and does not alter, correct, or supersede any claim made in the original reports.

Because the six source teams voluntarily deposited their reports on Zenodo under an open-access license, these documents are treated as openly licensed, publicly available scholarly records rather than as private or restricted student data. The competency ratings presented later in this paper (Section 3.3.3) are derived exclusively from claims the teams themselves made public in these reports; no non-public assessment data, grades, or personal information were accessed or analyzed.

3. Results

3.1. Extracted Reference Architecture

All six teams produced systems that share the same five-layer shape, differing only in vendor-adjacent implementation detail. Because four of these five layers correspond directly to a specific course day (Section 2.1), this architectural convergence is interpreted here primarily as a property of the course design, with the teams’ own engineering choices visible mainly in the connective and safety-related details layered on top of that shared skeleton (e.g., bidirectional write-back, relay placement, and the specific way each team wraps its AI layer).

(1) Sensing/actuation edge: an ESP32 microcontroller, programmed in MicroPython in five of six cases and in Arduino/C++ in one [13], simulated end-to-end in Wokwi rather than on physical hardware in every case a direct consequence of the Day 4 course specification.

(2) Edge decision logic: threshold-based classification executed locally on the ESP32 before any network call, so that the core sensing/alerting function survives connectivity loss in every case exhibiting this pattern; this design choice is not directly prescribed by the course and is treated as team-initiated.

(3) Cloud persistence: an Oracle APEX schema of three to five related tables, exposed through Oracle REST Data Services (ORDS), present in all six cases as a direct consequence of the Day 2 course specification.

(4) Mobile client: a MIT App Inventor application consuming the ORDS REST layer, with bidirectional write-back (remote actuation or manual override) implemented in four of six cases [14,15,17,18] the base client is prescribed by Day 3; write-back is team-initiated.

(5) Generative AI interpretation layer: a generative AI service invoked from either the firmware, an intermediary proxy, or the mobile client, implemented and positioned in four of six cases as an advisory or secondary function rather than the primary control decision-maker; proposed as a future explanation layer but not yet implemented in a fifth case; and tested only at the prompt level, not yet wired into any architecture, in the sixth (Section 3.2.2). The advisory framing is partially prescribed by Day 5; the fail-safe wrapping and local-first fallback behavior described in Section 3.2.2 go beyond what the course specifies.

This architecture is treated here as the artifact under evaluation in the design-science sense [10]: not a novel contribution proposed by any one team, but a pattern that the course’s five-day structure, combined with the teams’ own choices on the dimensions the course leaves open, reliably produces.

3.2. Cross-Case Findings

The cross-case coding matrix across the six literal-replication cases ais presented in Table 2, with each dimension classified by convergence type in details.

3.2.1. Architectural Convergence

All six teams reproduced the five-layer architecture of Section 3.1. As discussed above, the base shape of this architecture is largely explained by the course’s own day-by-day toolchain assignment rather than by independent team convergence; what varies meaningfully across teams and is therefore of more interest for this paper’s contribution is how each team filled in the connective tissue the course leaves unspecified (local-first decision logic, write-back, relay placement, and AI wrapping).

3.2.2. Generative AI and the Control Path

Because Day 5 already introduces generative AI as an advisory, interpretive layer rather than a control mechanism, the finding that no team lets a generative AI call directly gate a time-critical decision cannot be described as a fully independent discovery; it is more accurately described as a pattern that four of six teams implemented, extending and reinforcing it with their own fail-safe design choices beyond what the course specifies, while one further team (Case 4) proposed but did not implement such a layer, and one team (Case 5) did not integrate generative AI into any control-relevant path at all within the course week.

The hail/rain protection system computes its GRANIZO/heavy-rain classification locally first and only escalates to Gemini as a secondary classifier that is discarded on timeout, failure, or malformed response [14]. The precision-agriculture system runs identical local threshold logic for irrigation, climate, and lighting control and invokes Gemini only on demand from the mobile client for agronomic advice, never for the control loop itself [18]. The vital-sign monitoring team proposes, as a design principle for future implementation, that the generative model should serve strictly as a natural language explanation layer grounded in a prior rule-based or shallow-classifier decision rather than as an independent diagnostic decision-maker; this remains a proposed rather than implemented architecture [16]. The industrial energy monitor and the residential energy prototype both use their LLM purely for short diagnostic or pattern-report text generated after the control decision has already been made and, in the residential case, executed [13,15]; Table 1 records that Case 1 used a Groq-hosted LLM rather than Gemini. The fabric-softener waste-reduction team tested the Gemini API only at the level of an isolated prompt/response exchange, without wiring it into any control path [17], this case is therefore reported separately in Table 2 rather than folded into an undifferentiated “6 of 6” count.

With that distinction made explicit, four of six teams extended the course’s advisory framing into a genuine fail-safe separation between deterministic control and probabilistic advice consistent with, though not an independent confirmation of, the separation that constrained-IoT and human-factors literature treats as a design requirement rather than a default [4,20]. This is reported as the paper’s most interesting team-initiated finding, with the caveat above about its partially prescribed starting point.

3.2.3. Recurring Friction with Oracle APEX/ORDS at the Platform Level

Four of six teams independently encountered the same class of problems, namely that the Oracle APEX/ORDS platform’s transport-level defenses were rejecting or throttling requests from a constrained embedded client and independently converged on the same class of fix: interposing a relay or proxy on unconstrained hardware between the ESP32 and the cloud database. The industrial energy team built a Python 3.14 relay reachable via a Cloudflare Tunnel that performs the TLS-heavy handshake and impersonates a standard browser TLS fingerprint to satisfy the target’s bot-mitigation layer [13]. The vital-sign monitoring team encountered the same TLS/HTTP2 fingerprint filtering and used an intermediate proxy hosted on Google Colab for the same purpose [16]. The residential energy team routed every event through a Flask proxy reached via a public ngrok address [15], and the Agrosensor team deployed an always-on Node.js/Express proxy on Render specifically because network security restrictions imposed by Oracle APEX on direct HTTP requests from embedded devices made direct ESP32-to-APEX calls unreliable [18]. Even the hail/rain protection team, which posts directly to ORDS without a relay, found it necessary to space consecutive POST requests 400 ms apart specifically to avoid tripping the platform’s web application firewall [14]. Only the fabric-softener case, whose scope stopped short of a full production integration loop, did not report this friction. Because this convergence is neither specified by the course materials nor required by the rubric, it is classified in Table 2 as team-initiated.

3.2.4. Self-Reported Security Debt

Three of six teams explicitly flag credential handling as an unresolved risk in their own limitations sections. The hail/rain protection team states plainly that its Gemini API key was exposed in the publicly viewable Wokwi project and had to be revoked [14]; the same team separately flags that its ORDS endpoints accept writes with only a Content-Type header and no authentication token. The vital-sign monitoring team acknowledges that its AI-service credential is not yet isolated from client-side code and would need to move fully server-side before any real deployment [16]. The industrial energy team avoided the same problem by design, holding the Groq key exclusively inside its relay process rather than in firmware or the shared Wokwi project [13]. No team implemented per-device authentication on its write endpoints; this is read as a structural by-product of the shared, single-workspace Oracle APEX classroom configuration and the one-week timeline, rather than as six independent instances of the same oversight, and Table 2 reports it accordingly rather than as a team-initiated “6 of 6” convergence.

3.2.5. Breadth of SDG Alignment from One Fixed Toolkit

The same ESP32/Wokwi + Oracle APEX + App Inventor + generative AI toolchain was independently mapped by different teams onto five distinct primary Sustainable Development Goals: SDG 12 (Responsible Consumption and Production; [13,17], SDG 15/2/6/13 (Life on Land, with agricultural and climate linkages; [14]), SDG 11 (Sustainable Cities and Communities; [15]), SDG 3 (Good Health and Well-being; [16], and SDG 2 (Zero Hunger [18]). This SDG list is drawn directly from Table 1 and is used consistently throughout this section. This breadth is consistent, though on its own it does not prove the toolchain’s generality, since the SDG choice is also shaped by each team’s own domain interest rather than by the toolchain alone. Broader claims about generative educational technologies and SDG alignment beyond this cohort [21,22] are discussed separately in Section Related Work and are not treated as evidence about this specific case set.

3.2.6. Prescribed Versus Team-Initiated Convergence

Two convergences in the corpus are explicitly required by the course rather than team-initiated: every report closes with the same three-question rubric (value generated, client readiness, team readiness), and every report includes an appendix mapping its design to applicable IEEE/ISO IoT standards, most commonly IEEE 802.15.4, the IEEE 1451 smart-transducer family [23], and IEEE 2413/ISO IEC 30141 [19] reference-architecture guidance. These are reported separately from Section 3.2.1, Section 3.2.2, Section 3.2.3 and Section 3.2.4 because their convergence is expected by construction and carries different evidential weight than the architectural and AI-positioning convergences discussed above, several of which are themselves only partially, rather than fully, team-initiated (Section 3.2.1 and Section 3.2.2).

3.2.7. The Chilean Contrast Presentation (Illustrative Only)

As a discussion point only, the Chilean presentation described in Section 2.4 pursued a related idea a single predictive core deriving multiple value layers from unified telemetry on a categorically different stack: a Raspberry Pi and microcontroller pairing rather than an ESP32/Wokwi simulation, MQTT publish/subscribe messaging rather than direct REST calls, oneM2M as a horizontal service layer, ISO/IEC 30141 [19] as the reference architecture, and DLMS/COSEM for metering data exchange, with an earthquake early warning actuation layer added on top of routine electricity/gas/water monitoring. A structurally similar higher-level pattern is visible in this proposal: a fast, deterministic local decision executed at the edge, with any probabilistic or externally sourced signal (in this case, a simulated seismic early-warning frame rather than a generative AI classification) treated as an override input layered on top of, rather than as a replacement for, the local logic. This single, unverified, non-deposited data point is reported here descriptively as an interesting illustration; it is explicitly not used to support any claim that the six-case pattern is architectural rather than toolchain-specific, since a single case cannot bear that evidential weight.

3.3. Benchmarking Against the Institutional Competency Framework

Beyond the coding dimensions used in Section 3.2, Tecnológico de Monterrey’s institutional course catalog publicly lists the course’s competency codes and their required mastery levels (SICT0201B, SICT0303B, SICT0401B, SICT0402B, STC0207A/STE0104A/STI0301A, and SEG0201A, among others; [6]; the detailed behavioral descriptions used to define each rating level, however, are drawn from the institution’s internal competency dictionary and are condensed here rather than independently citable in full (

Table 3. The six internally documented sub-competencies for this course section, condensed with the course learning management.

Code	Competency (Tier)	Target Level	Description
SICT0201	Pattern Determination (Computing & IT)	Basic	Determine relevant patterns/trends in data using natural-science, mathematical, and computational fundamentals; propose a tool relating theory to observed data behavior using probabilistic, statistical, or classification methods.
SICT0303	Implementation of Actions (Computing & IT)	Basic	Implement scientific/engineering actions or computational processes matching the required solution type, integrating prioritization by significance, completeness, and optimality.
SICT0401	Application of Standards and Norms (Computing & IT)	Basic	Apply standards and norms as a reference in solving computational problems, ensuring regulatory compliance.
SICT0402	Application of Sustainability Principles (Computing & IT)	Basic	Apply sustainability principles in solving IT problems, identifying relevant Sustainable Development Goals.
STC0207/STE0104/STI0301	Project Management (Disciplinary)	Toward-Objective	Manage computing, information-technology, or technological-design projects through efficient use of resources, considering life cycle, resources, deliverables, and scope.
SEG0201	Innovation (General Education & Vision)	Toward-Objective	Generate innovative, valuable solutions via a validation process incorporating learning from positive and adverse situations, prototype-based validation, and empathy for the user, client, or beneficiary.

). This section benchmarks each team’s deposited manuscript against that internal framework as an illustrative exercise, not as a validated external audit, and asks a complementary, descriptive question: how consistently do the six teams’ deposited results evidence the institution’s own stated learning objectives, using the ratings and definitions below?

3.3.1. The Institutional Competency Framework

The internally documented learning objectives for the course section define six sub-competencies drawn from three tiers: Computing and Information Technologies competencies, a Disciplinary competency shared across the Software Systems Development/Embedded Systems/Digital Strategies tracks, and a General Education and Vision Support competency, each carrying an explicit target mastery level. Four competencies carry a “Basic” (B) target; two, project management and innovation, carry a higher “Toward-Objective” (TO) target.

The course’s official profile lists ten evaluated competencies in total; this benchmarking focuses on the six most directly evidenced by the deposited technical reports (SICT0201, SICT0303, SICT0401, SICT0402, Project Management, and Innovation), and does not assess SEG0202A/SEG0101A, which are evaluated through other course deliverables outside the scope of this synthesis.

3.3.2. Coding Approach

Each of the six deposited manuscripts was coded against the six competencies in Table 3, using explicit behavioral indicators derived from the institution’s published description for each rating: Strong (S) requires the manuscript to demonstrate the competency’s core described behavior with implemented, verifiable evidence; Partial (P) requires that evidence exists but is incomplete, deferred to future work, or addresses only part of the competency’s description; Limited (L) indicates the competency is not clearly evidenced by any of the above. An asterisk in

Table 4. Competency-level evidence across the six cases. S = Strong, P = Partial, L = Limited; P* = Partial, competency explicitly proposed but not yet implemented. Case numbers correspond to Table 1. These ratings were shared with the six corresponding teams prior to submission for factual review (Section 2.7).

Competency	Case 1	Case 2	Case 3	Case 4	Case 5	Case 6
SICT0201: Pattern Determination (B)	P	P	P	P*	L	P
SICT0303: Implementation of Actions (B)	S	S	S	P	P	S
SICT0401: Standards & Norms (B)	S	S	S	S	S	S
SICT0402: Sustainability Principles (B)	S	S	S	S	S	S
Project Management (TO)	S	S	P	S	S	P
SEG0201: Innovation (TO)	P	S	L	S	P	S

(Case 4, Pattern Determination) marks a competency that is explicitly proposed but not yet implemented; this rating is reported as Partial rather than as a separate “Strong-as-proposed” category, to keep the four-level ad hoc scale from diverging from the original three-level Strong/Partial/Limited definition.

3.3.3. Cross-Team Competency Matrix

The competency-level evidence across the six cases is presented in Table 4 in detail. These ratings were shared with the six corresponding teams prior to submission.

3.3.4. Competency-by-Competency Discussion

Pattern Determination (SICT0201, target Basic) is the most weakly evidenced competency in the cohort. Five of six teams implemented deterministic threshold logic (fixed power/temperature limits, fixed distance deltas, fixed analog-count cutoffs) rather than the probabilistic, statistical, or classification methods the competency specifies, and used their generative AI layer for natural language diagnostics rather than trend detection [13,15,17,18]. SPAI-EH’s two-tier local-threshold-plus-Gemini-classification design is closer to genuine pattern classification but still resolves to a deterministic rule at the tier that matters for actuation [14]. Only the vital-sign monitoring team designed an approach matching the competency’s literal wording: weak-supervision labeling, a candidate-model ladder from rule-based threshold to logistic regression to gradient-boosted trees, and confusion-matrix-based evaluation under class imbalance, though this was explicitly left unimplemented as future work rather than delivered [16], which is why Table 4 marks it Partial (proposed) rather than Strong. Read together with Section 3.2.2, the cohort’s preference for deterministic, local decision logic identified as a strength for safety in Section 3.2.2 is simultaneously a plausible explanation for why the cohort under-delivers on the specific statistical-modeling competency the course targets at only a “Basic” level; this reading is offered as a plausible interpretation, not a demonstrated causal claim.

Implementation of Actions (SICT0303, target Basic) is strongly evidenced in four of six cases, through fully implemented, tested control loops with documented actuation [13,14,15,18]. The vital-sign monitoring and fabric-softener teams show partial evidence: both implemented and verified a working data pipeline but explicitly scoped out full end-to-end control or production integration within the week [16,17].

Application of Standards and Norms (SICT0401) and Sustainability Principles (SICT0402), both target Basic, are strongly evidenced across all six cases, but this near-unanimous result should be read alongside Section 3.2.6: the course explicitly requires an SDG mapping and an IEEE/ISO standards appendix from every team, so Strong ratings here reflect a prescribed deliverable at least as much as independent team initiative. Depth still varies: the vital-sign monitoring team’s standards appendix is unusually thorough for a one-week prototype, additionally citing the ISO 81060-2 clinical validation protocol for blood-pressure devices [16,24,25], and the fabric-softener and Agrosensor teams map to five and three standards respectively with explicit field-level justification [17,18].

Project Management (STC0207/STE0104/STI0301, target Toward-Objective) shows more variable evidence, consistent with this competency’s higher target level. SPAI-EH and the fabric-softener team show the strongest evidence: the former through an explicit bill-of-materials and cost table weighing hardware cost against documented hail-damage losses [14], the latter through a documented project-selection process in which the team voted among four candidate projects before scoping the chosen one into five objectives [17]. The industrial energy and vital-sign monitoring teams also show strong evidence, through an explicit five-phase methodology with role-based author contributions [13] and an explicit three-phase implementation log with transparent remaining-work reporting [16], respectively. The residential energy and Agrosensor teams show partial evidence: both are organized cleanly by architectural layer but do not document an explicit phase, timeline, or resource-allocation artifact to the same degree.

Innovation (SEG0201, target Toward-Objective) is most strongly evidenced by SPAI-EH, which explicitly assesses the smallholder grower’s readiness, notes the region’s reliance on post hoc government compensation rather than preventive tooling, and recommends a subsidized or cooperative deployment model tailored to that context [14]. The vital-sign monitoring and Agrosensor teams also show strong evidence, the former through an extended discussion of interpretable-versus-opaque models, alarm fatigue, and clinician/user trust [16], the latter through an explicit phased-adoption strategy addressing smallholder farmers’ digital-literacy and capital constraints [18]. The industrial energy and fabric-softener teams show partial evidence, with clear value framing but comparatively less user-context validation. The residential energy team shows the most limited evidence, having explicitly scoped itself as an academic proof of concept rather than a user-validated solution [15].

3.3.5. Synthesis

Two descriptive patterns are visible in Table 4. First, the four “Basic”-level competencies split into a near-unanimous group (standards, sustainability) that is at least partly explained by prescribed course deliverables, and a weakly evidenced outlier (pattern determination) that is plausibly related to the deterministic-local-control habit identified in Section 3.2.2. Second, the two “Toward-Objective” competencies (project management, innovation) split the cohort roughly in half between Strong and Partial evidence. This is consistent with but does not on its own independently validate the institution’s own framework treating Toward-Objective as a harder bar than Basic, since the same six cases and the same coders are used for both the observation and the comparison; this is reported as a descriptive alignment rather than as independent evidence for the framework’s difficulty gradient.

4. Discussion

The central empirical claim of this paper is modest: within one course structure that prescribes much of the resulting system shape, six unrelated student teams produced the same five-layer architecture and, largely building on the course’s own advisory framing of generative AI, converged with only limited additional prompting on keeping generative AI out of every safety or time-critical decision. Because the course specifies most of the architecture directly, this second finding is interpreted cautiously here: what is genuinely of interest for IoT curriculum design is not that a five-layer system appeared, but that even a first, brief exposure to LLM integration on the final day of a five-day course was sufficient for four of six teams to extend that exposure into their own fail-safe separation between deterministic control and probabilistic advice a separation that constrained-IoT and human-factors literature treats as a design requirement rather than a default [4].

The recurring friction with Oracle APEX/ORDS (Section 3.2.3) is a more clearly team-initiated and immediately actionable finding: four of six teams spent debugging time on the same class of platform-level problem, and all four independently reinvented a similar fix (an external relay on unconstrained hardware). A future iteration of the course could shorten this by teaching the relay pattern explicitly on Day 2, rather than leaving each team to rediscover it during Day 4 integration work.

The consistent absence of endpoint authentication (Section 3.2.4) is best read as a property of the one-week timeline and the shared classroom Oracle APEX workspace rather than as six independent instances of the same skills gap; three of six teams flagged it themselves without prompting, which is itself evidence of the reflective quality the course rubric is designed to elicit.

The Chilean contrast case (Section 3.2.7) cannot be used to make a statistical claim; it is a single, unverified illustrative data point on a fundamentally different stack, but its descriptive resemblance to the six cases on the “local-decision-first, external-signal-as-override” pattern is offered as a discussion point for future, more rigorously designed comparative work rather than as boundary evidence in its own right.

Beyond architecture, several risks limit how far generative AI integration should be trusted in this setting. First, large language models such as Gemini may produce inaccurate, incomplete, or misleading outputs (hallucinations); AI-generated recommendations should be treated as decision-support suggestions rather than authoritative instructions. Second, reliance on cloud infrastructure means system responsiveness depends on internet connectivity and third-party service availability. Third, free usage tiers support initial experimentation, but higher-volume use would incur operational costs that institutions must evaluate for long-term deployment. Finally, AI outputs require human oversight: students and instructors must critically evaluate AI recommendations for relevance and feasibility before applying them, consistent with treating AI as a decision-support tool rather than an autonomous decision-maker in this prototyping context.

5. Limitations

• Small, non-random sample: six literal-replication cases plus one non-deposited, non-generalizable contrast case supports, at most, analytic generalization to a pattern observed in this specific course and cohort; it does not support statistical generalization to a population of courses or teams.
• Course-structure confound because the course prescribes most of the architecture and part of the AI-advisory framing directly, several convergence findings reported here cannot be cleanly separated from the course design itself; Table 2’s convergence-type column is an attempt to make this explicit, but the underlying confound cannot be fully resolved with this study design. This difficulty is consistent with broader findings that time-bounded, event-style learning formats such as hackathons generally lack a standardized method for isolating format-driven from participant-driven learning outcomes [6,7].
• Single institution, single instructor, single one-week cohort (Tecnológico de Monterrey, MNA, July 2026): course-effect, instructor-effect, and toolchain-effect cannot be separated within this design.
• All six literal-replication cases were validated only in Wokwi simulation; the failure-mode and security findings inherit this limitation directly from the source manuscripts and should not be read as claims about physical-hardware behavior.
• Coding was performed by a single primary coder who was also the shared faculty advisor across the six source manuscripts; a co-author reviewed the coding for face validity but was not a fully independent reviewer, since he is also a co-author of this synthesis rather than an uninvolved third party, and no formal inter-rater reliability statistic (e.g., Cohen’s kappa) was computed. This is a disclosed limitation rather than a resolved methodological safeguard.
• The institutional competency framework used in Section 3.3 is sourced from an internal, non-public learning-management page; its benchmarking should be read as illustrative rather than as an externally auditable competency assessment.
• The Chilean contrast case is deliberately under-specified here (Section 2.4) to honor the collaborator’s request; readers should treat Section 3.2.7 as illustrative rather than as a fully citable, independently verifiable case.
• This synthesis evaluates identifiable, named student teams’ work. As disclosed in the Institutional Review Board Statement, the authors determined that formal ethical review was not required; this determination is the authors’ own assessment rather than an exemption issued by an institutional review board, and no consent beyond the teams’ own voluntary open-access deposition was sought. This is disclosed as a limitation of the study’s ethics documentation, not as an item pending completion.

6. Conclusions and Future Work

Six independently authored, one-week IoT prototypes built on the same ESP32/Wokwi, Oracle APEX/ORDS, MIT App Inventor, and generative AI toolchain produced a common five-layer reference architecture substantially shaped by the course’s own day-by-day structure and, largely extending the course’s own advisory framing, a shared fail-safe habit of keeping generative AI advisory rather than authoritative in four of six implemented cases, with a fifth case proposing the same pattern as future work and a sixth testing generative AI only at the prompt level. They also converged, in a more clearly team-initiated way, on a shared class of platform-level friction with Oracle APEX/ORDS and a shared, self-acknowledged gap in endpoint authentication. A structurally different, contrast proposal from a Chilean collaborator is discussed as a suggestive but non-generalizable illustration that the higher-level local-decision-first pattern may extend beyond this specific toolchain; this remains an open question for future work rather than a demonstrated finding.

Future work should: (1) teach the relay/proxy pattern identified in Section 3.2.3 explicitly and earlier in the course sequence; (2) introduce a minimal per-device authentication requirement as a Day 2 deliverable rather than leaving it as a documented but unresolved limitation; (3) address the weak evidence on the Pattern Determination competency (Section 3.3.4) directly for example, by adding a short, optional Day 5 module on lightweight statistical or classification methods (e.g., simple logistic-regression or threshold-calibration exercises) so that teams have a concrete, time-bounded path to the competency’s probabilistic/statistical requirement; (4) extend this synthesis with a physical-hardware replication of at least one case to test whether the Wokwi-only failure modes persist on real silicon; (5) design a follow-up study capable of disentangling course-prescribed from team-initiated convergence more rigorously than a single-cohort document analysis allows for example, by comparing cohorts taught with different sequencing of the AI module; and (6) repeat this cross-case design with a subsequent cohort, this time with a documented inter-rater reliability procedure and a fully independent, non-advisor reviewer, to test whether the AI-positioning pattern reported here is a stable property of the course rather than a one-cohort, single-coder artifact.