Submission declined on 18 August 2026 by Sulfurboy (talk). This draft's references do not show that the subject meets Wikipedia's criteria for inclusion. The draft requires multiple published secondary sources that: provide significant coverage: discuss the subject in detail, not just brief mentions or routine announcements; are reliable: from reputable outlets with editorial oversight; are independent: not connected to the subject, such as interviews, press releases, the subject's own website, or sponsored content. Please add references that meet all three of these criteria. If none exist, the subject is not yet suitable for Wikipedia. If you would like to continue working on the submission, click on the "Edit" tab at the top of the window. If you have not resolved the issues listed above, your draft will be declined again and potentially deleted. If you need extra help, please ask us a question at the AfC Help Desk or get live help from experienced editors. Please do not remove reviewer comments or this notice until the submission is accepted. Where to get help If you need help editing or submitting your draft, please ask us a question at the AfC Help Desk or get live help from experienced editors. These venues are only for help with editing and the submission process, not to get reviews. If you need feedback on your draft, or if the review is taking a lot of time, you can try asking for help on the talk page of a relevant WikiProject. Some WikiProjects are more active than others so a speedy reply is not guaranteed. How to improve a draft Wikipedia:Contributing to Wikipedia – a basic overview on how to edit Wikipedia. Help:Wikitext – how to use the markup Help:Referencing for beginners – how to include references Wikipedia:Article development – how to develop your article Wikipedia:Writing better articles – how to improve your article Wikipedia:Verifiability – make sure your article includes reliable third-party sources You can also browse Wikipedia:Featured articles and Wikipedia:Good articles to find examples of Wikipedia's best writing on topics similar to your proposed article. Improving your odds of a speedy review To improve your odds of a faster review, tag your draft with relevant WikiProject tags using the button below. This will let reviewers know a new draft has been submitted in their area of interest. For instance, if you wrote about a female astronomer, you would want to add the Biography, Astronomy, and Women scientists tags. Add tags to your draft Editor resources Easy tools: Citation bot (help) | Advanced: Fix bare URLs Declined by Sulfurboy 7 days ago. Last edited by Sulfurboy 7 days ago. Reviewer: Inform author. Resubmit Please note that if the issues are not fixed, the draft will be declined again.

• Comment: Relies too heavily on primary sourcing and does not demonstate a pass of WP:GNG. Please focus on what secondary sources say about the subject and why secondary sources consider it notable. Sulfurboy (talk) 00:39, 18 August 2026 (UTC)

Language of Things (LoT) is a domain-specific language for IoT automation. It uses a near-English, declarative syntax to define logic, data structures, integrations, and access control, all executed inside the Coreflux MQTT broker rather than in a separate application process.^[1] The concept was created by Hugo Vaz, a co-founder of Coreflux, while attending a linguistics course taught by Ana Maria Brito on generative grammar in the tradition of Noam Chomsky.^[2][3][4] Vaz has described LoT as an abstraction layer for the factory floor: the engineer states intent—actions, models, routes, and rules—while the broker remains the runtime, in the same way C sat on top of the 8051 and 8086 without erasing the machine underneath.^[2] The language first appeared in 2023 as Flux Lang and was renamed Language of Things by Paulo Mota, also a Coreflux co-founder.^[5][4]

Programs are built from four constructs, each introduced with the DEFINE keyword: Actions (event-driven logic), Models (structured data schemas on MQTT topics), Routes (connections to external systems), and Rules (who may publish, subscribe, or administer the broker).^[1] Statements such as PUBLISH, SET, and GET operate on MQTT topics and payloads.^[1] A model describes fields and types; the wire encoding is chosen separately, so the same definition can be published as JSON, Protocol Buffers, or both.^[6][7]

Hugo Vaz, one of the co-founders of Coreflux, created the concept of Language of Things while attending a class of Ana Maria Brito devoted to linguistics and the work of Noam Chomsky.^[2][3][4] Brito is a retired full professor of linguistics at the University of Porto Faculty of Arts and Humanities (FLUP), where she taught syntax in the generative tradition and directed master's and doctoral programmes in linguistics and language sciences.^[3] The classroom work on how a small set of rules can generate an open-ended language sat alongside Vaz's earlier training on bare metal: the 8051 and 8086, then C and C++, each layer stating more intent and less opcode.^[2][3]

In a 2026 essay, Vaz wrote that industrial IoT still repeats the pre-C pattern. A plant with a Modbus PLC typically requires a custom poller—endianness, register types, topic tree, retries, a simulator for when the hardware is offline—and a later job on OPC UA starts from another blank file.^[2] He argued that the 8086 did not need a new architecture for every program, only a language that already understood what a program was, and that LoT should play that role on the factory floor: the facts (a register map, a drive's IP address) stay explicit, while the wiring around them is no longer rewritten each morning.^[2]

The idea entered Coreflux in 2023 under the working name Flux Lang. Paulo Mota, a co-founder of the company, renamed it Language of Things (LoT).^[4][5][1] The broker implements the language; templates at templates.coreflux.org sit one layer above it, in the same way C libraries sat above the compiler: a notebook that already ran (Modbus polling, OPC UA to MQTT, a Kafka bridge) is adapted instead of being authored from scratch.^[2][8] Vaz has also framed the language's density as a response to large language models: because the broker already provides sessions, quality of service, and scheduling, generated LoT can keep more of a plant in a model's context window than an equivalent Python client, loop, and SDK.^[2]

LoT is designed so that transformation, routing, and policy for live MQTT streams can be declared in the broker instead of being implemented as external microservices.^[1][7] Official documentation compares this role to SQL for real-time MQTT data: the programmer states the desired structure and reactions, and the broker compiles and runs the definitions when they are uploaded.^[1]

Definitions can be written as plain .lot source, as notebook files (.lotnb) that mix markdown with LoT and optional Python cells, or deployed by publishing to the broker command topic $SYS/Coreflux/Command.^[7][9] A public sample repository and a template library of ready-to-run notebooks cover industrial protocols, databases, and common automations.^[7][8]

The official introduction's first example is a time-based action. Once deployed, the broker publishes ok to system/alive every five seconds, with no external client loop:^[1]

DEFINE ACTION Heartbeat
ON EVERY 5 SECONDS DO
    PUBLISH TOPIC "system/alive" WITH "ok"

A second one-line pattern forwards whatever arrives on one topic to another. ON TOPIC is an MQTT subscription; PUBLISH TOPIC is an MQTT publish; PAYLOAD is the triggering message:^[1]

DEFINE ACTION Echo
ON TOPIC "input/message" DO
    PUBLISH TOPIC "output/message" WITH PAYLOAD

Either snippet can be pasted into a LoT Notebook cell and run, or published to $SYS/Coreflux/Command.^[10][7]

Everything in LoT is created with DEFINE.^[1]

Actions are executable blocks that run inside the broker. They can fire on a schedule (ON EVERY), on every matching MQTT message (ON TOPIC), only when a payload changes (ON CHANGE), or as callable utilities invoked by other actions. They support conditionals, topic-position extraction, JSON field reads, publishing, and optional calls into Python for calculations that need external libraries.^[11]

A model is the abstract schema—named, typed fields (STRING, INT, DOUBLE, BOOL, and others)—not a commitment to one on-the-wire format. The language is encoding-agnostic: the same model can be emitted as JSON (the default), as binary Protocol Buffers (WITH FORMAT PROTOBUF or PROTO), or as both (WITH FORMAT BOTH, JSON on the model topic and protobuf bytes on a /protobuf child topic).^[6][7] Protobuf fields may carry a PROTO_TAG so the wire numbers match an external .proto file; actions read those payloads with GET PROTO or GET PROTOBUF in the same way they read JSON with GET JSON.^[7]

Models can aggregate values from several MQTT topics, mark a field as the trigger, and attach timestamps or constants. Incoming structured payloads on a model topic can be split into per-field child topics.^[6]

DEFINE MODEL SensorReading WITH FORMAT JSON WITH TOPIC "sensors/formatted"
    ADD STRING "id" WITH "TEMP001"
    ADD DOUBLE "value" WITH TOPIC "sensors/raw" AS TRIGGER

DEFINE MODEL ProtoTimestamp WITH FORMAT PROTOBUF
    ADD INT "seconds" PROTO_TAG 1
    ADD INT "nanos" PROTO_TAG 2

Routes declare managed connections from the broker to other systems. Documented families include industrial protocols (Modbus, Siemens S7, OPC UA, EtherNet/IP, Allen-Bradley, Omron FINS, BACnet), databases (PostgreSQL, MySQL, SQL Server, MongoDB, OpenSearch), streaming (Apache Kafka), HTTP (REST), email, MQTT bridges and clusters, and AI/MCP integrations.^[12][7]

Rules are the broker's access-control language. A rule has a priority, a scope (for example Publish, Subscribe, Connect, or entity-management operations such as creating actions), and an ALLOW/DENY decision based on user, client, or topic conditions.^[9]

The following program, from the official language introduction, combines all four constructs: a model formats raw sensor topics as JSON, an action publishes an alert when temperature exceeds a threshold, a route stores sensor traffic in PostgreSQL, and a rule restricts who may publish to alert topics.^[1]

DEFINE MODEL SensorReading WITH TOPIC "sensors/+/formatted"
    ADD STRING "sensor_id" WITH TOPIC "sensors/+/id"
    ADD DOUBLE "temperature" WITH TOPIC "sensors/+/raw" AS TRIGGER
    ADD STRING "unit" WITH "celsius"
    ADD STRING "timestamp" WITH TIMESTAMP "UTC"

DEFINE ACTION TemperatureAlert
ON TOPIC "sensors/+/formatted" DO
    SET "sensor_id" WITH TOPIC POSITION 2
    SET "temp" WITH (GET JSON "temperature" IN PAYLOAD AS DOUBLE)
    IF {temp} > 80 THEN
        PUBLISH TOPIC "alerts/" + {sensor_id} + "/high_temp" WITH "Temperature above threshold"

DEFINE ROUTE SensorDB WITH TYPE POSTGRESQL
    ADD SQL_CONFIG
        WITH SERVER "postgres.example.com"
        WITH PORT '5432'
        WITH DATABASE "iot_data"
        WITH USERNAME "iot_user"
        WITH PASSWORD "secure_password"
    ADD EVENT StoreSensorData
        WITH SOURCE_TOPIC "sensors/#"
        WITH QUERY "INSERT INTO sensor_readings (topic, payload) VALUES ('{topic}', '{value.json}')"

DEFINE RULE RestrictAlertPublish WITH PRIORITY 10 FOR Publish TO TOPIC "alerts/#"
    IF USER HAS AllowedSystemAlerts OR USER IS "root" THEN
        ALLOW
    ELSE
        DENY

Topic wildcards follow MQTT conventions (+ for one level, # for a subtree). TOPIC POSITION is 1-based.^[1][7]

A LoT Notebook (file extension .lotnb) is the usual way to write and ship a LoT system. It is a cell-based file, similar in spirit to a Jupyter notebook, that keeps documentation and executable definition in one place: Markdown cells describe the system; code cells hold DEFINE ACTION, DEFINE MODEL, DEFINE ROUTE, and DEFINE RULE blocks, and may also contain Python.^[10][7] Official documentation calls this pairing living documentation: the prose is the recipe, and running a LoT cell deploys that step to the connected broker.^[10]

The public LOT-Samples repository is organised the same way. Guides sit next to uploadable .lot source for heartbeats, topic routers, industrial routes (Modbus, Siemens S7, OPC UA), databases, and complete systems that combine an action, a model, and a rule. A notebook—or the matching .lot file—is what gets uploaded; the samples are checked against the broker parser.^[7] Ready-made notebooks for plants and devices are also published at templates.coreflux.org.^[8]

Vaz has argued that a system has to be described, not only executed, and that the notebook is a search for that form: one artefact in which the explanation and the running definition can be read together. He presents that search as unfinished work shared beyond any one company—documentation and code as a single account of what the system is.^[2][10]

LoT Notebooks are edited and deployed with a Visual Studio Code extension (LoT Notebooks by Coreflux). Running a code cell sends the definition to the broker; a data viewer can subscribe to topics to watch the result.^[10] Definitions can also be published to the command topic $SYS/Coreflux/Command.^[9]

• MQTT
• Internet of things
• Domain-specific language
• Publish–subscribe pattern
• SQL
• Node-RED
• Noam Chomsky
• Generative grammar
• University of Porto
• Project Jupyter
• Protocol Buffers
• JSON

• Introduction to LoT — official language documentation
• LOT-Samples — community examples for actions, models, routes, and rules
• Coreflux LoT Templates — ready-to-run LoT notebooks
• Language of Things — product overview
• From 8051 to LoT — Hugo Vaz on abstraction, LoT, and templates
• Hugo Vaz — personal site of the language's designer
• Ana Maria Brito — CIÊNCIAVITAE profile

Category:Domain-specific programming languages Category:Declarative programming languages Category:Internet of things Category:Message-oriented middleware Category:2020s software