Pith. sign in

REVIEW 4 major objections 6 minor 52 references

AutoIoT: Automated IoT Platform Using Large Language Models

T0 review · 4 major / 6 minor · reviewed 2026-08-12 · deepseek-v4-flash

Challenge this review Re-run · record.json Download PDF Read on arXiv ↗ Review JSON

Pith's one-line read The paper proposes AutoIoT, an LLM-based pipeline that turns device photos and manuals into formally verified, conflict-free smart-home automation rules.

desk verdict A plausible integration of known pieces whose 'conflict-free' guarantee is undermined by an ambiguous cascading-conflict definition; worth refereeing, not worth accepting as is. read the letter →

arxiv 2411.10665 v1 pith:F55OA326 submitted 2024-11-16 cs.CR

Ye Cheng , Minghui Xu , Yue Zhang , Kun Li , Ruoxi Wang , Lian Yang This is my paper · ORCID
classification cs.CR
keywords smarthomeautomationruleslargelanguagemodelstrigger-actionprogrammingconflictdetectionformalverificationMaudeIoTplatforms
verification ladder T0 review T1 audit T2 compute T3 formal

The pith

A machine-rendered reading of the paper's core claim, the machinery that carries it, and where it could break.

The reading

The paper is trying to show that a user with no programming or automation knowledge can upload photos of their smart-home devices, optionally with manuals and a preference in natural language, and receive automation rules that are conflict-free. The proposed system, AutoIoT, uses a multimodal LLM and a CNN to extract device information, an LLM to generate trigger-action rules, and a formal verification step to detect conflicts; when conflicts are found, an LLM revises the rules. The paper also claims this is the first end-to-end automation platform, because rule generation, conflict detection, and conflict avoidance are all automatic rather than manual. A code-generation adapter separates logical reasoning from syntax, letting an LLM emit verification code for a formal language that is sparse in typical LLM training data. The motivation is to lower the knowledge barrier for smart-home users and to spare developers from hand-writing conflict-detection code.

What carries the argument

The central mechanism is the code generation adapter built on a three-function template—model_device, model_state_transition, and model_initial_state—which lets the LLM write logical verification calls in a familiar Python-like form while the adapter translates them into Maude rewrite rules. Around this sits the four-type conflict taxonomy, with Maude search commands checking reachable home states for conflicting state pairs in the state and environment conflict sets, and for cascading conditions across rule chains. The template is what makes the end-to-end claim work, because it lets an LLM that has almost no Maude training data still generate correct verification code.

What would settle it

Give AutoIoT two rules that never touch the same device and never trigger each other but together draw enough power to trip a circuit breaker, for example 'motion detected -> heater on' and 'door opened -> kettle on', and check whether the Maude search returns 'no solution'. Under the paper's taxonomy nothing in the state or environment conflict sets is violated, so a 'no conflict' result would be a false negative if the physical deployment trips the breaker.

Watch

Extended reading notes

Core claim

The central claim is that a single pipeline can carry a smart home from raw device images to deployed, conflict-free automation rules with no manual rule authoring and no manual verification-code writing. AutoIoT formalizes devices as tuples of ID, type, actions, states, and location, and rules as trigger-action transitions; it defines four conflict types—state, environment, state cascading, and state-environment cascading—and encodes them in Maude rewrite rules. The LLM generates both the automation rules and the verification logic, while a code adapter converts the LLM's template-level calls into syntactically valid Maude code for the formal verification tool. In the reported case study with ten smart-home devices, the system generated ten rules and the Maude search returned no conflicting states. The contribution is the integration: prior platforms require users or developers to write rules and detection code, while AutoIoT automates both.

Load-bearing premise

The load-bearing premise is that the four conflict types defined in the paper cover every harmful interaction between automation rules, and that the Maude code produced by the code adapter checks exactly those conditions.

Editorial extensions

If this is right

  • Users without programming skills can go from device photos and a stated preference to deployment-ready rules, because rule generation and the formal check are both automatic.
  • Platform developers can add conflict detection without writing verification code by hand; the adapter converts the LLM's template-level logic into executable Maude code.
  • Prompting with the four conflict definitions steers rule generation away from those conflicts before verification, so the formal step is a confirmation rather than a repair in the common case.
  • Because the adapter decouples logic from syntax, the same generation pipeline can target other low-resource formal languages or domain-specific languages.
  • AutoIoT can hand rules to an existing platform in natural language or as runnable scripts, so the end-to-end automation does not require replacing the user's current smart-home system.

Reading between the lines

Editorial extensions of the paper, not claims the author makes directly.

  • Editorial inference: The strongest test of the safety claim is a recall study: feed AutoIoT a labeled corpus of rule pairs with known harmful interactions and measure how many the Maude search catches; the paper's single case study cannot establish this.
  • Editorial inference: The code adapter is a general trick: any formal language with scarce training data could be exposed through a small template API, letting an LLM reason in a familiar form and translate later.
  • Editorial inference: The 'conflict-free' label should be read as 'free of the four declared conflict types.' If the state-cascading and state-environment cascading definitions remain imprecise, the label is weaker than it appears.
  • Editorial inference: A natural extension is to prove or disprove completeness of the four-type taxonomy, for example by enumerating interaction classes from a larger survey of smart-home incidents and checking each against the formal definitions.
Share X Bluesky LinkedIn Reddit HN

Editorial analysis

A structured set of objections, weighed in public.

Desk editor's note, referee report, and a circularity audit.

Referee Report

4 major / 6 minor

Summary. The paper proposes AutoIoT, an automated smart-home platform that uses LLMs to extract device information from images/manuals, generate trigger-action automation rules from natural-language preferences, translate rules into formal verification code via a 'code adapter', detect conflicts with the Maude rewriting-logic system, and optimize rules when conflicts are found. The authors claim this is the first end-to-end IoT automation pipeline covering rule generation, conflict detection, and avoidance, reducing the burden on both end users and developers. The manuscript includes an architecture description, four prompt designs, a prototype implementation, time-cost measurements across four LLMs, and a ten-device case study on Mi Home.

Significance. If the central safety claim were sound, AutoIoT would be a useful systems contribution showing how LLM-based natural interaction can be combined with formal verification for smart-home automation. The paper has tangible strengths: it presents a concrete end-to-end pipeline, publishes the prompts and template used for code generation, uses an existing formal tool (Maude), and reports a real deployment case study. The idea of a code adapter that separates logical structure from target-language syntax is potentially valuable for extending LLM code generation to low-resource formal languages. However, the current manuscript does not adequately support the load-bearing claims: the formal conflict definitions are imprecise, the completeness of the four conflict types is asserted rather than proved, the code adapter is described only at a high level, and the evaluation measures only time cost without testing whether conflict detection is actually correct. For these reasons, the contribution is promising but not yet established.

major comments (4)
  1. [Section IV-D] The formal definitions of state cascading and state-environment cascading conflicts are not well-formed. The statement 'a state Cascading conflict exists if ∀si ∈ Si, si ∈ S′1 ∪ S′2 ∪ · · · ∪S′k' uses an unsubscripted Si, does not quantify over rules, and does not express the informal notion that the resulting state of one rule becomes an initial state of another. As written, the condition is too strong (any rule whose initial-state set contains a state not produced by any rule is never flagged, even when a genuine cascade exists) and too weak (a subset condition among sets does not establish a chain among rules). The description of the Maude isExist() functions in Section IV-D-2 ('determine whether the current HomeState contains Si of an automation rule Ri during the simulation of the other automation rules') suggests a different, existential semantics than the written universal formula. Please provide a precise formal definition, for example ∃i,j with i ≠ j and S_i ∩ S′_j ≠ ∅ for cascading conflicts, and ensure the Maude encoding checks exactly that condition.
  2. [Section IV-D] The paper asserts that the four conflict types (state, environment, state cascading, state-environment cascading) are sufficiently complete to make generated rules 'conflict-free', but no proof or precise semantic model is given. The claim appears in the sentence 'we first provide a clear definition of four types of conflicts' and is used to justify the Maude 'no solution' result as evidence of conflict-freeness in Section V-C. Because the safety guarantee is relative to this taxonomy, the manuscript should either define a formal model of rule execution and a notion of harmful interaction, then prove that every harmful interaction falls into one of the four categories, or explicitly restrict the safety claim to the four listed conflict types. Without this, a 'no conflict' result from Maude does not establish that the rules are actually safe.
  3. [Section IV-D-1] The code adapter is a central component of the claimed contribution, but the manuscript does not specify how the LLM-generated Python-style 'logic code' is translated into Maude code and does not release the generated Maude code for inspection. Section IV-D-1 presents the template and then states that 'AutoIoT uses the code generation adapter to convert ⟨logic code⟩ into Maude codes', but the conversion rules are not given. This makes it impossible to check whether the Maude encoding faithfully represents the intended conflict definitions, which is essential for the case study's 'no solution' claim. Please provide the adapter's implementation or a formal specification of the translation, and include the actual Maude code for the case study or a representative example.
  4. [Section V-B] The evaluation measures only time costs: Section V-B reports latency for information extraction, rule generation, code generation, and conflict detection, and Table VI compares time ratios across LLMs. There is no measurement of whether the generated rules are correct, whether the conflict detection has high precision/recall, or whether the adapter produces syntactically and semantically correct Maude code. The case study in Section V-C reports that Maude returns 'no solution' for ten generated rules, but no ground truth or manual audit is provided to confirm that conflicts were absent or that the rules are actually useful. To support the central claim of conflict-free rule generation, please add a correctness evaluation, such as testing on a labeled set of conflicting and non-conflicting rule pairs, or a detailed manual analysis of the case-study rules.
minor comments (6)
  1. [Section IV-D] In the definitions of state conflict and environment conflict, the quantification '∃s′_i, s′_j ∈ S′_i ∪ S′_j' is ambiguous because both quantified variables range over the entire union rather than over the respective resulting-state sets of two distinct rules. If cross-rule conflicts are intended, please write ∃s′_i ∈ S′_i and ∃s′_j ∈ S′_j with i ≠ j such that (s′_i, s′_j) ∈ CS (or CE).
  2. [Section V-C] In the paragraph 'Conflict-free Automation Rules Generation', the text says 'LLM-LoT produced the formal verification logic'; this appears to be a typo for 'AutoIoT' and should be corrected.
  3. [Figure 9] The JSON in Figure 9 contains a stray curly quotation mark in rule8 ('"trigger”"') and, more substantively, uses 'Door and Window Sensor turned on' as a trigger state, while the device model presented earlier uses states like 'open' and 'closed' for door/window sensors; please align the state terminology used in the example with the formal device model.
  4. [Table I] The caption of Table I does not explain the meaning of the '!' and '%' symbols used in the cells; please add a legend or use checkmarks and crosses for clarity.
  5. [Section IV-A] The paragraph acknowledging that LLMs could be compromised by poisoning or backdoor attacks correctly identifies a limitation, but it is placed abruptly in the middle of the formal model subsection; consider moving this to a dedicated limitations or threat-model discussion and specifying the assumed trust boundary more precisely.
  6. [References] Reference [23] ('CP-IoT: A cross-platform monitoring system for smart home') lacks venue and publication details; please provide complete bibliographic information.

Circularity Check

0 steps flagged · score 0.0 of 10

No significant circularity: the Maude verification is an independent check and the conflict taxonomy is a specification, not a self-derived result.

full rationale

AutoIoT's central claim is that LLM-generated rules are checked by a separate Maude formal-verification step. The paper explicitly states 'we cannot guarantee that the generated rules are entirely free from conflicts. Therefore, we next need to detect conflicts among these rules' (Section IV-D), so the Maude 'no solution' result is not a restatement of the generation prompt. The same four conflict definitions appear both in Table III (rule-generation context) and in Section IV-D (formal specification), but that is the normal relationship between a property specification and a verifier, not a derivation of the property from itself; the Maude search can in principle fail on rules that satisfy the prompt. The cited prior work for the conflict definitions, [23], [28], [30], is external rather than self-citation, and the paper's self-citations ([26], [33], [39], [41], [42]) appear only in background and preliminaries and do not carry the safety claim. The formal definition of state cascading conflict ('∀si ∈ Si, si ∈ S′1 ∪ S′2 ∪ · · · ∪S′k') is under-specified and may not match the intended existential cascade condition, and the generated Maude code is not released for inspection; these are soundness and verifiability risks, not circularity. No load-bearing step reduces to its own input by construction, so the appropriate finding is no significant circularity.

Assumptions & free parameters 0 free parameters · 4 assumptions · 1 invented entities

The central claims of conflict-free rule generation and developer-friendly formal verification rest on the completeness of the conflict taxonomy, the faithfulness of the Maude encoding, the accuracy of the CNN and LLM extraction, and the correctness of the code adapter. None of these premises are validated against external ground truth or released artifacts.

assumptions (4)
  • ad hoc to paper The four conflict types (state, environment, state cascading, state-environment cascading) are a complete taxonomy of harmful automation-rule interactions.
    The paper asserts this completeness without proof or external benchmark. The definitions in Section IV-D drive both rule generation and verification.
  • domain assumption Maude faithfully models the semantics of the automation rules and its search is exhaustive over all relevant executions.
    The paper relies on Maude as a sound verification engine (Section IV-D.2), but provides no Maude code or search-bound details, so this faithfulness cannot be checked.
  • domain assumption The CNN and LLMs extract device information and generate automation rules with sufficient accuracy for the downstream verification to be meaningful.
    Section IV-C assumes accurate device lists; however, no accuracy metrics for the CNN or the LLM extraction are reported, and the case study is the only evidence.
  • ad hoc to paper The code adapter translates the LLM-generated logic code into Maude code without introducing semantic errors.
    The adapter is introduced to address syntactic errors (Section IV-D.1), but its semantic correctness is not independently verified and its implementation is not released.
invented entities (1)
  • Code generation adapter
    purpose: Separates the logical structure of conflict-detection code, expressed as Python template functions, from the syntactic details of Maude, so that LLMs can generate Maude code without training data in Maude.
    The adapter is a new software component introduced in Section IV-D.1. Its correctness is not demonstrated beyond a single anecdotal case study, and no code for the adapter is released, so there is no falsifiable handle outside the paper.

how reviews work

0 comments
Cite this review

Pith. "Pith review of AutoIoT: Automated IoT Platform Using Large Language Models." pith.science (2026). https://pith.science/paper/F55OA326

@misc{pith2026241110665,
  author       = {Pith},
  title        = {Pith review of: AutoIoT: Automated IoT Platform Using Large Language Models},
  year         = {2026},
  howpublished = {\url{https://pith.science/paper/F55OA326}},
  note         = {Machine review of arXiv:2411.10665}
}
read the original abstract

IoT platforms, particularly smart home platforms providing significant convenience to people's lives such as Apple HomeKit and Samsung SmartThings, allow users to create automation rules through trigger-action programming. However, some users may lack the necessary knowledge to formulate automation rules, thus preventing them from fully benefiting from the conveniences offered by smart home technology. To address this, smart home platforms provide pre-defined automation policies based on the smart home devices registered by the user. Nevertheless, these policies, being pre-generated and relatively simple, fail to adequately cover the diverse needs of users. Furthermore, conflicts may arise between automation rules, and integrating conflict detection into the IoT platform increases the burden on developers. In this paper, we propose AutoIoT, an automated IoT platform based on Large Language Models (LLMs) and formal verification techniques, designed to achieve end-to-end automation through device information extraction, LLM-based rule generation, conflict detection, and avoidance. AutoIoT can help users generate conflict-free automation rules and assist developers in generating codes for conflict detection, thereby enhancing their experience. A code adapter has been designed to separate logical reasoning from the syntactic details of code generation, enabling LLMs to generate code for programming languages beyond their training data. Finally, we evaluated the performance of AutoIoT and presented a case study demonstrating how AutoIoT can integrate with existing IoT platforms.

Figures

Figures reproduced from arXiv: 2411.10665 by the authors.

Figure 1
Figure 1. The architecture of AutoIoT. Understanding these elements is crucial because they allow us to effectively communicate our intentions to the model. By carefully crafting the prompt, we can guide the model’s behavior and improve the quality of its responses. These elements provide the necessary structure and context for the model to generate accurate and meaningful outputs [44]. B. Formal Verification Formal verificat… view at source ↗
Figure 2
Figure 2. Two types of images for device information extraction. (a) App [PITH_FULL_IMAGE:figures/full_fig_p005_2.png] view at source ↗
Figure 3
Figure 3. An example of LLM-generated automation rules. [PITH_FULL_IMAGE:figures/full_fig_p006_3.png] view at source ↗
Figures from the paper (7 more)
Figure 4
Figure 4. Figure 4: The examples of four different conflicts. [PITH_FULL_IMAGE:figures/full_fig_p007_4.png]
Figure 5
Figure 5. Figure 5: The code generation template for formal verification. [PITH_FULL_IMAGE:figures/full_fig_p008_5.png]
Figure 6
Figure 6. Figure 6: The time cost for device information extraction, rule generation, code [PITH_FULL_IMAGE:figures/full_fig_p009_6.png]
Figure 7
Figure 7. Figure 7: AutoIoT Assisted Smart Home. Fig.7 demonstrates our AutoIoT assisted smart home case study. When a user buys some IoT devices, the user first adds the devices to the corresponding IoT platform through its app. To get some safe automation rules, the user takes photos of…
Figure 8
Figure 8. Figure 8: The device deployment topology of the case study. [PITH_FULL_IMAGE:figures/full_fig_p010_8.png]
Figure 10
Figure 10. Figure 10: Examples of deploying the automation rules. (a) Using Mi Home [PITH_FULL_IMAGE:figures/full_fig_p011_10.png]
Figure 9
Figure 9. Figure 9: 10 automation rules generated by LLM. Automation Rules Deployment. After receiving the au￾tomation rules, we tried two deployment schemes to add them to the Mi Home platform. As shown in [PITH_FULL_IMAGE:figures/full_fig_p011_9.png]

Discussion (0). Continue with ORCID to comment.

Reference graph

Works this paper leans on

52 extracted references · 35 canonical work pages

  1. [1]

    Sic 2: Securing microcontroller based iot devices with low-cost crypto coprocessors,

    B. Pearson, C. Zou, Y . Zhang, Z. Ling, and X. Fu, “Sic 2: Securing microcontroller based iot devices with low-cost crypto coprocessors,” in 2020 IEEE 26th International Conference on Parallel and Distributed Systems (ICPADS). IEEE, 2020, pp. 372–381

    work page 2020

  2. [2]

    When good becomes evil: Tracking bluetooth low energy devices via allowlist-based side channel and its countermeasure,

    Y . Zhang and Z. Lin, “When good becomes evil: Tracking bluetooth low energy devices via allowlist-based side channel and its countermeasure,” in Proceedings of the 2022 ACM SIGSAC Conference on Computer and Communications Security, 2022, pp. 3181–3194

    work page 2022

  3. [3]

    Breaking secure pairing of bluetooth low energy using downgrade attacks,

    Y . Zhang, J. Weng, R. Dey, Y . Jin, Z. Lin, and X. Fu, “Breaking secure pairing of bluetooth low energy using downgrade attacks,” in29th USENIX Security Symposium (USENIX Security 20) , 2020, pp. 37–54

    work page 2020

  4. [4]

    Riotfuzzer: Companion app assisted remote fuzzing for detecting vulnerabilities in iot devices,

    K. Liu, M. Yang, Z. Ling, Y . Zhang, C. Lei, J. Luo, and X. Fu, “Riotfuzzer: Companion app assisted remote fuzzing for detecting vulnerabilities in iot devices,” in Proceedings of the 31th Conference on Computer and Communications Security (CCS’24) , 2024

    work page 2024

  5. [5]

    Collapse like a house of cards: Hacking building automation system through fuzzing,

    Y . Zhang, Z. Ling, M. Cash, Q. Zhang, C. Morales-Gonzalez, Q. Z. Sun, and X. Fu, “Collapse like a house of cards: Hacking building automation system through fuzzing,” in Proceedings of the 31th Conference on Computer and Communications Security (CCS’24) , 2024

    work page 2024

  6. [6]

    A friend’s eye is a good mirror: Synthesizing {MCU} peripheral models from peripheral drivers,

    C. Lei, Z. Ling, Y . Zhang, Y . Yang, J. Luo, and X. Fu, “A friend’s eye is a good mirror: Synthesizing {MCU} peripheral models from peripheral drivers,” in 33rd USENIX Security Symposium (USENIX Security 24) , 2024, pp. 7085–7102. 12

    work page 2024

  7. [7]

    Apple. Homekit. [Online]. Available: https://www.apple.com/tv-home/

  8. [8]

    Smartthings

    Samsung. Smartthings. [Online]. Available: https://www.samsung.com/ us/smartthings/

Show all 52 references
  1. [9]

    Xiaomi. Mi home. [Online]. Available: https://home.mi.com

  2. [10]

    Google. Nest. [Online]. Available: https://home.nest.com

  3. [11]

    Automating conflict detection and mitigation in large-scale iot systems,

    P. Pradeep, A. Pal, and K. Kant, “Automating conflict detection and mitigation in large-scale iot systems,” in 2021 IEEE/ACM 21st Interna- tional Symposium on Cluster, Cloud and Internet Computing (CCGrid) , 2021, pp. 535–544

    2021

  4. [12]

    Conflict detection scheme based on formal rule model for smart building systems,

    Y . Sun, X. Wang, H. Luo, and X. Li, “Conflict detection scheme based on formal rule model for smart building systems,” IEEE Transactions on Human-Machine Systems , vol. 45, no. 2, pp. 215–227, 2015

    2015

  5. [13]

    A formal methods-based rule verification framework for end-user programming in campus building automation systems,

    H. Ibrhim, S. Khattab, K. Elsayed, A. Badr, and E. Nabil, “A formal methods-based rule verification framework for end-user programming in campus building automation systems,” Building and Environment , vol. 181, p. 106983, 2020. [Online]. Available: https://www.sciencedirect.c...

    2020

  6. [14]

    Scalable analysis of interaction threats in iot systems,

    M. Alhanahnah, C. Stevens, and H. Bagheri, “Scalable analysis of interaction threats in iot systems,” in Proceedings of the 29th ACM SIGSOFT International Symposium on Software Testing and Analysis, ser. ISSTA 2020. New York, NY , USA: Association for Computing Machinery, 2020...

    2020

  7. [15]

    Multi-platform application interaction extraction for iot devices,

    Z. Chen, F. Zeng, T. Lu, and W. Shu, “Multi-platform application interaction extraction for iot devices,” in 2019 IEEE 25th International Conference on Parallel and Distributed Systems (ICPADS) , 2019, pp. 990–995

    2019

  8. [16]

    Cross-app interference threats in smart homes: Categorization, detection and handling,

    H. Chi, Q. Zeng, X. Du, and J. Yu, “Cross-app interference threats in smart homes: Categorization, detection and handling,” in 2020 50th Annual IEEE/IFIP International Conference on Dependable Systems and Networks (DSN), 2020, pp. 411–423

    2020

  9. [17]

    Chart- ing the attack surface of trigger-action iot platforms,

    Q. Wang, P. Datta, W. Yang, S. Liu, A. Bates, and C. A. Gunter, “Chart- ing the attack surface of trigger-action iot platforms,” in Proceedings of the 2019 ACM SIGSAC conference on computer and communications security, 2019, pp. 1439–1453

    2019

  10. [18]

    Iotguard: Dynamic enforce- ment of security and safety policy in commodity iot,

    Z. B. Celik, G. Tan, and P. D. McDaniel, “Iotguard: Dynamic enforce- ment of security and safety policy in commodity iot,” in 26th Annual Network and Distributed System Security Symposium, NDSS 2019, San Diego, California, USA, February 24-27, 2019 . The Internet Society, 2019

    2019

  11. [19]

    Understanding and automatically detecting conflicting interactions between smart home iot applications,

    R. Trimananda, S. A. H. Aqajari, J. Chuang, B. Demsky, G. H. Xu, and S. Lu, “Understanding and automatically detecting conflicting interactions between smart home iot applications,” in Proceedings of the 28th ACM Joint Meeting on European Software Engineering Conference and Sy...

    2020

  12. [20]

    Amazon. Alexa. [Online]. Available: https://alexa.amazon.com

  13. [21]

    Design and imple- mentation of a framework for smart home automation based on cellular iot, mqtt, and serverless functions,

    M. Esposito, A. Belli, L. Palma, and P. Pierleoni, “Design and imple- mentation of a framework for smart home automation based on cellular iot, mqtt, and serverless functions,” Sensors, vol. 23, no. 9, p. 4459, 2023

    2023

  14. [22]

    Detecting and handling IoT interaction threats in Multi-Platform Multi-Control-Channel smart homes,

    H. Chi, Q. Zeng, and X. Du, “Detecting and handling IoT interaction threats in Multi-Platform Multi-Control-Channel smart homes,” in 32nd USENIX Security Symposium (USENIX Security 23) . Anaheim, CA: USENIX Association, Aug. 2023, pp. 1559–1576. [Online]. Available: https://ww...

    2023

  15. [23]

    Cp-iot: A cross-platform monitoring system for smart home

    H. Lin, C. Li, J. Yang, Z. Wang, L. Fan, and C. Duan, “Cp-iot: A cross-platform monitoring system for smart home.”

  16. [24]

    Philips. Hue. [Online]. Available: https://www.philips-hue.com

  17. [25]

    A cloud-based smart iot platform for personalized healthcare data gathering and monitoring system,

    S. S. Vellela, V . L. Reddy, R. D, G. R. Rao, K. B. Sk, and K. K. Kumar, “A cloud-based smart iot platform for personalized healthcare data gathering and monitoring system,” in 2023 3rd Asian Conference on Innovation in Technology (ASIANCON) , 2023, pp. 1–5

    2023

  18. [26]

    Tbac: A tokoin-based accountable access control scheme for the internet of things,

    C. Liu, M. Xu, H. Guo, X. Cheng, Y . Xiao, D. Yu, B. Gong, A. Yerukhi- movich, S. Wang, and W. Lyu, “Tbac: A tokoin-based accountable access control scheme for the internet of things,” IEEE Transactions on Mobile Computing, vol. 23, no. 5, pp. 6133–6148, 2024

    2024

  19. [27]

    Extracting spatial infor- mation of iot device events for smart home safety monitoring,

    Y . Wan, X. Lin, K. Xu, F. Wang, and G. Xue, “Extracting spatial infor- mation of iot device events for smart home safety monitoring,” in IEEE INFOCOM 2023 - IEEE Conference on Computer Communications , 2023, pp. 1–10

    2023

  20. [28]

    Iotsafe: Enforcing safety and security policy withreal iot physical interaction discovery,

    W. Ding, H. Hu, and L. Cheng, “Iotsafe: Enforcing safety and security policy withreal iot physical interaction discovery,” in Network and Distributed System Security Symposium , 2021

    2021

  21. [29]

    Command- fence: A novel digital-twin-based preventive framework for securing smart home systems,

    Y . Xiao, Y . Jia, Q. Hu, X. Cheng, B. Gong, and J. Yu, “Command- fence: A novel digital-twin-based preventive framework for securing smart home systems,” IEEE Transactions on Dependable and Secure Computing, vol. 20, no. 3, pp. 2450–2465, 2023

    2023

  22. [30]

    A survey on conflict detection in iot-based smart homes,

    B. Huang, D. Chaki, A. Bouguettaya, and K.-Y . Lam, “A survey on conflict detection in iot-based smart homes,” ACM Computing Surveys , vol. 56, no. 5, pp. 1–40, 2023

    2023

  23. [31]

    A model checking-based security analysis framework for iot systems,

    Z. Fang, H. Fu, T. Gu, Z. Qian, T. Jaeger, P. Hu, and P. Mohapatra, “A model checking-based security analysis framework for iot systems,” High-Confidence Computing, vol. 1, no. 1, p. 100004, 2021

    2021

  24. [32]

    A survey of large language models,

    W. X. Zhao, K. Zhou, J. Li, T. Tang, X. Wang, Y . Hou, Y . Min, B. Zhang, J. Zhang, Z. Dong, Y . Du, C. Yang, Y . Chen, Z. Chen, J. Jiang, R. Ren, Y . Li, X. Tang, Z. Liu, P. Liu, J.-Y . Nie, and J.-R. Wen, “A survey of large language models,” 2024. [Online]. Available: https:...

    2024 arXiv

  25. [33]

    Attention is all you need for llm-based code vulnerability localization,

    Y . Li, X. Li, H. Wu, Y . Zhang, X. Cheng, S. Zhong, and F. Xu, “Attention is all you need for llm-based code vulnerability localization,” arXiv preprint arXiv:2410.15288, 2024

    2024 arXiv

  26. [34]

    A survey of data augmentation approaches for nlp,

    S. Y . Feng, V . Gangal, J. Wei, S. Chandar, S. V osoughi, T. Mitamura, and E. Hovy, “A survey of data augmentation approaches for nlp,”

  27. [35]

    Low-code llm: Graphical user interface over large language models,

    Y . Cai, S. Mao, W. Wu, Z. Wang, Y . Liang, T. Ge, C. Wu, W. You, T. Song, Y . Xia, J. Tien, N. Duan, and F. Wei, “Low-code llm: Graphical user interface over large language models,” 2024. [Online]. Available: https://arxiv.org/abs/2304.08103

    2024 arXiv

  28. [36]

    Using an llm to help with code understanding,

    D. Nam, A. Macvean, V . Hellendoorn, B. Vasilescu, and B. Myers, “Using an llm to help with code understanding,” in Proceedings of the IEEE/ACM 46th International Conference on Software Engineering, ser. ICSE ’24. New York, NY , USA: Association for Computing Machinery,

  29. [37]

    3d-llm: Injecting the 3d world into large language models,

    Y . Hong, H. Zhen, P. Chen, S. Zheng, Y . Du, Z. Chen, and C. Gan, “3d-llm: Injecting the 3d world into large language models,” Advances in Neural Information Processing Systems , vol. 36, pp. 20 482–20 494, 2023

    2023

  30. [38]

    Large language models (llm) and chatgpt: what will the impact on nuclear medicine be?

    I. L. Alberts, L. Mercolli, T. Pyka, G. Prenosil, K. Shi, A. Rominger, and A. Afshar-Oromieh, “Large language models (llm) and chatgpt: what will the impact on nuclear medicine be?” European journal of nuclear medicine and molecular imaging , vol. 50, no. 6, pp. 1549–1552, 2023

    2023

  31. [39]

    On protecting the data privacy of large language models (llms): A survey,

    B. Yan, K. Li, M. Xu, Y . Dong, Y . Zhang, Z. Ren, and X. Cheng, “On protecting the data privacy of large language models (llms): A survey,”

  32. [40]

    A survey on large language model (llm) security and privacy: The good, the bad, and the ugly,

    Y . Yao, J. Duan, K. Xu, Y . Cai, Z. Sun, and Y . Zhang, “A survey on large language model (llm) security and privacy: The good, the bad, and the ugly,” High-Confidence Computing , vol. 4, no. 2, p. 100211, 2024. [Online]. Available: https://www.sciencedirect.com/ science/arti...

    2024

  33. [41]

    Conu: Conformal uncertainty in large language models with correctness coverage guarantees,

    Z. Wang, J. Duan, L. Cheng, Y . Zhang, Q. Wang, X. Shi, K. Xu, H. Shen, and X. Zhu, “Conu: Conformal uncertainty in large language models with correctness coverage guarantees,”arXiv preprint arXiv:2407.00499, 2024

    2024 arXiv

  34. [42]

    Available: https://arxiv.org/abs/2403.05156

    [Online]. Available: https://arxiv.org/abs/2403.05156

    arXiv

  35. [43]

    Elements of a prompt

    DAIR.AI. Elements of a prompt. [Online]. Available: https://www. promptingguide.ai/introduction/elements

  36. [44]

    Prompt engineering with chatgpt: a guide for academic writers,

    L. Giray, “Prompt engineering with chatgpt: a guide for academic writers,” Annals of biomedical engineering , vol. 51, no. 12, pp. 2629– 2633, 2023

    2023

  37. [45]

    Word-sequence entropy: Towards uncer- tainty estimation in free-form medical question answering applications and beyond,

    Z. Wang, J. Duan, C. Yuan, Q. Chen, T. Chen, H. Yao, Y . Zhang, R. Wang, K. Xu, and X. Shi, “Word-sequence entropy: Towards uncer- tainty estimation in free-form medical question answering applications and beyond,” arXiv preprint arXiv:2402.14259 , 2024

    2024 arXiv

  38. [46]

    A. C. C. C. Ltd. Tongyi. [Online]. Available: https://tongyi.aliyun.com/

  39. [47]

    iFLYTEK. Spark. [Online]. Available: https://xinghuo.xfyun.cn/

  40. [48]

    International

    S. International. The maude system. [Online]. Available: https: //maude.cs.illinois.edu/

  41. [49]

    OpenAI. Chatgpt. [Online]. Available: https://chatgpt.com/

  42. [51]

    ByteDance. Dou bao. [Online]. Available: https://www.doubao.com/

  43. [2021]

    Available: https://arxiv.org/abs/2105.03075

    [Online]. Available: https://arxiv.org/abs/2105.03075

    arXiv

  44. [2024]

    Available: https://doi.org/10.1145/3597503.3639187

    [Online]. Available: https://doi.org/10.1145/3597503.3639187

Pith tools

Reviewed August 12, 2026 · model on record in the stance chip above.