{"id":"d977a07d-a12b-485a-8ca6-16d18760beb8","arxiv_id":"2411.13400","paper_version":1,"verdict":"CONDITIONAL","confidence":"HIGH","novelty_score":3.0,"correctness_risk":"medium","formal_verification":"none","parameter_count":1,"one_line_summary":"QRind is a new QR-code-embedded programming dialect that adds variables and a small neural network to the authors' existing QRtree decision-tree dialect for offline industrial assistance.","lead":"QRind is a new programming language small enough to be stored inside a QR code, so a smartphone can run a tiny machine-learning model with no Internet connection. It targets factory maintenance: a printed label could run a diagnosis program that asks for measured values and then guides the worker to the right fix.","discovery_kind":"extension","skeptic_critique":{"model":"deepseek-v4-flash","headline":"The Section IV capacity estimate counts only ANN coefficients; the eQRbytecode mapping that would prove the full program fits in 2953 bytes is deferred to future work in Section V, so the MLP-in-a-QR claim remains unverified.","rationale":"I read the paper in good faith. The narrowest contribution, a definition of the QRind intermediate language with variables and three ML instructions, is present and internally coherent: Table I lists the instructions, Section III describes the MLP forward pass, and Section IV's worked example is mathematically correct (the sigmoid output for 60 C and 1000 RPM is 0.53, and 551 coefficients yield 1102/2204 bytes). The weak point is neither the language design nor the example, but the absence of the binary encoding that would convert the intermediate representation into an eQRbytecode small enough to fit inside a QR code. The paper itself acknowledges this gap in Section V, listing the binary mapping as future work. Because the abstract's readiness claim and Section IV's capacity estimate both depend on that mapping, this is a load-bearing concern rather than a minor omission. It is also the same concern the reader identified as the weakest assumption, so my assessment agrees. The correct verdict remains CONDITIONAL: the paper is a reasonable specification of an intermediate language, but it does not yet demonstrate the operational claim that a 20x25x1 MLP plus control logic can fit in and run from a single QR code. I did not find a separate internal inconsistency that would justify REJECT, and I did not find the work so complete that an ACCEPT would be warranted without the binary encoding and an end-to-end QR generation test.","tokens_in":6943,"tokens_out":4429,"duration_ms":51889,"concrete_test":"Define a concrete eQRbytecode for all eight QRind instructions using the QRtree conventions (e.g., 3-bit opcode, exponential register indexes, raw float16/float32 weight payloads, length-prefixed UTF-8 strings), encode the Section IV 20x25x1 MLP program including all input prompts and string literals, and generate the resulting QR code at ECC levels L, M, Q, and H. If the byte length exceeds 2953 at level L, or 1273 at level H, the Section IV capacity claim fails; if it only fits at L, the claim must be qualified by error-correction level.","verdict_should_be":"UNCHANGED","load_bearing_attack":"The central claim, as stated in the abstract and Section IV, is that QRind lets a single QR code embed an MLP (20x25x1) plus control logic and execute it offline. The quantitative anchor is 1102 bytes (float16) or 2204 bytes (float32) for the 551 network coefficients, and the arithmetic is correct. However, that count covers only the weight payload. Section V explicitly says: 'we will define precisely how to optimally map every instruction to the corresponding binary representation.' No opcode table, no register/array encoding, no string encoding, and no generated QR code are provided. Thus the 2953-byte budget is never checked against a real eQRbytecode artifact. Every instruction in Table I needs an opcode; register indices use the exponential encoding from QRtree; arrays, labels, and input prompts need metadata; and the example's string literals and multiple INPUT instructions also consume bytes. Moreover, 2953 bytes is only the capacity of version 40 at error correction level L; levels M, Q, and H reduce it substantially (1273 bytes at H). If the binary encoding is not sufficiently compact, the 20x25x1 MLP plus I/O scaffolding will not fit, and the operational claim about offline Industry 4.0/5.0 support is unsupported. The paper's own admission in Section V is therefore the load-bearing gap: the dialect's intermediate representation and example are coherent, but the binary layer on which all capacity and execution claims depend is missing.","agreement_with_reader":"agree"},"referee_report":{"model":"deepseek-v4-flash","summary":"The paper proposes QRind, a new dialect for executable QR codes (eQR/sQRy) that extends the existing QRtree decision-tree dialect with variables and three machine-learning instructions (MLINPUT, NNLAYER, MLOUTPUT). The paper defines the intermediate representation, presents a running example of a two-input sigmoid MLP used for condition-based maintenance, and claims that a single QR code can store a 20x25x1 MLP because the 551 coefficient values occupy 1102 (float16) or 2204 (float32) bytes. The binary encoding (eQRbytecode) that would turn the intermediate representation into an actual QR-code payload is explicitly deferred to future work in Section V.","tokens_in":7077,"tokens_out":4316,"duration_ms":44758,"significance":"The dialect semantics are coherent and the quantitative anchors are correct: the sigmoid forward pass through Eq. (2) gives approximately 0.53 for 60 C and 1000 RPM, and the coefficient counts for a 20x25x1 MLP are plain arithmetic (551 parameters). If the binary mapping were supplied, QRind would be a useful, compact intermediate language for embedding small ML models in offline QR-based industrial guides. However, because the eQRbytecode layer is explicitly future work, the paper currently validates only the intermediate representation, not the executable-code claims in the title and abstract. The contribution is therefore at the design/proposal stage, and the capacity claim is unsupported.","major_comments":[{"comment":"The paper's own future-work statement in Section V concedes that the mapping from QRind instructions to eQRbytecode is not defined ('As future work, we will define precisely how to optimally map every instruction to the corresponding binary representation'). This mapping is load-bearing for the central claims of 'Executable QR codes' and offline ML execution, because a QR code can only contain a finite binary payload. Without an opcode table, register/array encoding, string encoding, and a generated QR artifact, the claim that the MLP example fits in a QR code is unverified.","section":"Section V"},{"comment":"The byte-count estimate (1102/2204 bytes) is correct as an arithmetic statement about the 551 coefficients, but it does not constitute a capacity argument for the whole program. It omits instruction opcodes, register declarations, array metadata, string literals, label/jump targets, and QR error-correction overhead. The 2953-byte ceiling cited in Section II is version 40 at error-correction level L; levels M/Q/H reduce it to 2331/1663/1273 bytes. A complete byte budget, ideally accompanied by a generated QR code, is needed to support the claim that a 20x25x1 MLP plus control logic fits in a single QR code.","section":"Section IV"},{"comment":"The QRind specification is incomplete for implementation: there is no formal grammar or semantics for how MLINPUT and multiple NNLAYER instructions compose layer dimensions, what happens when an MLP is fed fewer inputs than declared, or the byte order and alignment of float16/float32 weights. These details affect both the binary encoding and the virtual-machine behavior, so they should be specified or explicitly deferred with consequences for the feasibility claims made in Section IV.","section":"Section III, Table I"}],"minor_comments":[{"comment":"The sentence 'The first five instructions are aimed at managing the decision trees' is imprecise; SET, INPUT, and PRINT are general-purpose assignment and I/O instructions, and only TREECONDITION and TREEJUMP are tree-specific.","section":"Section III, Table I"},{"comment":"The prose after Eq. (2) says the warning message is 'Problem! Is the oil level fine?' while Fig. 3, line (11) reads 'Problem! Is the oil level low?'; the text and the figure should be consistent.","section":"Section IV"},{"comment":"The phrase 'up to 2953 bytes' should be qualified with the QR version and error-correction level, since that figure is only the maximum at version 40-L.","section":"Section II"},{"comment":"In the calculation following Eq. (2), consider showing the intermediate value (about 0.525) rather than only the rounded 0.53, to make the arithmetic transparent.","section":"Section IV"},{"comment":"The claim that the binary mapping process is 'relatively straightforward' is an unsupported assertion; it should either be demonstrated or removed.","section":"Section V"}],"recommendation":"major_revision","confidential_remarks":"The paper is a short proposal whose central feasibility claim rests on a binary encoding that the authors themselves defer to future work. If the authors supply the encoding and a concrete byte budget, the paper may become acceptable. I see no signs of citation manipulation or scope mismatch; the issue is technical completeness."},"author_rebuttal":null,"desk_editor":{"model":"deepseek-v4-flash","letter":"What you should know: this is a short conference paper that defines QRind, a new eQR dialect adding variables and three ML instructions (MLINPUT, NNLAYER, MLOUTPUT) to the 7-instruction QRtree baseline. That is genuinely new relative to the cited corpus, and the instruction set is coherent. The worked example checks out: I reproduced the sigmoid forward pass (60 C and 1000 RPM give 0.53) and the capacity arithmetic (a 20x25x1 MLP has 551 coefficients, so 1102 bytes in float16, 2204 in float32). The paper is honest about its limits: Section V explicitly says the eQRbytecode mapping is future work, and the abstract's Industry 4.0/5.0 offline claim reads more as a vision than a demonstrated capability.\n\nWhere it is soft: the capacity statement counts only weights. It omits opcodes, register declarations, array metadata, labels, string literals, and the QR error-correction overhead (2953 bytes is version 40 at level L; level H allows only 1273). So the specific claim that a single QR code can embed this MLP plus control logic is not yet shown. The gap is real but not hidden—the authors flag it themselves. If the encoding turns out inefficient, the flagship example may not fit. There is also no bytecode, no virtual machine, no generated QR code, and no compactness comparison with QRtree. For a short design-proposal paper, this is acceptable if the claims are framed accordingly.\n\nThe math that is present is right, and the citation pattern is reasonable; they cite their own QRtree/QRscript specifications, which are the relevant prior works. There is no fitted-then-relabeled-as-predicted issue.\n\nWho this is for: people working on embedded or offline QR-code interaction, or on squeezing tiny ML models into constrained media. The paper gives a clean intermediate representation for decision-tree-plus-small-MLP programs and a worked example. It deserves a serious referee; the main ask should be to either add a concrete encoding or soften the capacity/offline claims to match what is actually shown.","headline":"QRind is a coherent new dialect with correct small examples, but the paper's own Section V defers the binary encoding that would prove the MLP-in-a-QR claim.","tokens_in":7833,"tokens_out":2227,"would_cite":true,"duration_ms":23648,"reading_group":"maybe","serious_thinker":"yes","would_accept_peer_review":true},"rs_alignment":null,"lean_confirmation":null,"pith_extraction":{"msc":[],"pacs":[],"model":"deepseek-v4-flash","headline":"The paper proposes QRind, a QR-code language dialect that packs decision-tree logic and a small neural network into a scannable square so maintenance guidance runs offline on a smartphone.","keywords":["executable QR codes","eQR codes","QRind dialect","QRtree","machine learning","multilayer perceptron","predictive maintenance","offline computing"],"falsifier":"Translate the paper's own running example, or the 20-25-1 MLP example, into a concrete QRind bytecode, generate an actual version-40 QR code, and verify the encoded program fits and executes; if the 20-25-1 MLP with its control instructions exceeds 2953 bytes, the central feasibility claim fails.","tokens_in":6555,"feed_emoji":"🤖","tokens_out":5654,"duration_ms":49243,"temperature":0.7,"pith_summary":"This paper proposes QRind, a new instruction set for executable QR codes that lets a program scanned from a physical label carry both decision-tree guidance and a small machine learning model. The point is to enable predictive-maintenance assistance on a smartphone with no Internet connection: the QR code itself contains the logic and the model. QRind keeps the compactness of the earlier QRtree dialect but adds registers for variables and three machine-learning instructions that describe a multi-layer perceptron layer by layer. If the approach works, any printed industrial label can become an offline diagnostic agent.","feed_headline":"QR codes embed neural nets to keep machines running offline","feed_subtitle":"New QR dialect QRind packs decision logic and a small neural net into one scannable square that works offline.","key_machinery":"The QRind instruction set includes the existing decision-tree instructions SET, INPUT, PRINT, TREECONDITION, TREEJUMP, plus the machine-learning instructions MLINPUT, NNLAYER, and MLOUTPUT. MLINPUT maps a register array to the model inputs; NNLAYER specifies one layer by neuron count, activation type, weight encoding, and an ordered weight list that lists for each neuron its incoming weights and bias; MLOUTPUT maps the model output to a register. The layer computation is the standard MLP forward pass $out_i = f(\\sum_{j=1}^{n_l} w_{ij} x_j + b_i)$, and register indexing uses the exponential encoding from QRtree so that commonly used registers take fewer bits.","core_discovery":"In the paper's own terms, QRind is a dialect of the QRscript executable-QR-code language that extends the existing QRtree decision-tree dialect with variable registers and three instructions, MLINPUT, NNLAYER, and MLOUTPUT, so that a neural network and the decision logic that uses its output can travel together inside a QR code and run offline on a smartphone. The running example couples a 2-input, 1-output sigmoid MLP with a small decision tree that asks the user about oil level, and the authors estimate that a single version-40 QR code can hold a 20-input, 25-hidden-neuron, 1-output MLP: 1102 bytes of weights in float16 or 2204 bytes in float32, leaving room for control instructions in the 2953-byte capacity.","pith_inferences":["We infer that a practical QRind toolchain will need a compiler that generates near-optimal bytecode for the whole instruction stream, not just for weights, and that this step, left as future work, will determine whether the advertised model sizes actually fit.","The same MLINPUT, NNLAYER, MLOUTPUT pattern could in principle be generalized to other model classes, such as small convolutional or decision-forest models, by adding new ML type codes, since the language separates model transport from execution.","A testable extension would be to measure end-to-end execution time and power consumption on low-end smartphones, because QRind bytecode is interpreted by a virtual machine and MLP inference adds computational load per scan.","If a compact bytecode is achieved, printed industrial labels could serve as local applications that never need firmware updates, since the program and model are in the label itself, but the label must be replaced whenever the model changes."],"forward_implications":["Mobile maintenance apps can run a full diagnosis cycle, ask for sensor values, run a neural network, branch on its output, and print guidance, with no network access.","Because every byte matters, float16 weight encoding nearly doubles the neural-network size that fits in a given QR code compared with float32.","QRind should be able to represent not only MLPs but, through the same register and control instructions, broader decision logic that mixes user interaction with model output.","The QRscript virtual machine must be extended with QRind's three ML instructions and its data types for QRind programs to execute."],"supporting_citations":[{"why":"Defines QR code versions and the 2953-byte capacity that bounds any QRind program.","marker":"[7]"},{"why":"Specifies the QRscript language that the QRind dialect extends.","marker":"[8]"},{"why":"Introduces the idea of embedding a programming language in QR codes for decision and management.","marker":"[9]"},{"why":"Positions eQR codes as executable QR technology and establishes the generation and execution chain.","marker":"[10]"},{"why":"Supplies the QRtree dialect, the exponential register encoding, and the conversion-rule template QRind follows.","marker":"[11]"}],"fun_headline_variants":["Neural nets now fit inside QR codes for offline industry use","QR codes get machine learning smarts for offline factories","One QR code can now carry a neural net and run offline","Offline QR codes now run built-in machine learning models","QR code packs a neural net for offline industrial guidance"],"cache_read_input_tokens":3200,"weakest_assumption_plain":"The whole QRind program, including opcodes, register declarations, array metadata, and the model weights, must fit into the 2953-byte limit of a version-40 QR code, but the paper only estimates the weight bytes and leaves the binary encoding unspecified.","fun_headline_variants_meta":{"raw":{"variants":["Neural nets now fit inside QR codes for offline industry use","QR codes get machine learning smarts for offline factories","One QR code can now carry a neural net and run offline","Offline QR codes now run built-in machine learning models","QR code packs a neural net for offline industrial guidance"]},"model":"deepseek-v4-flash","effort":"low","cost_usd":0.000762,"raw_usage":{"total_tokens":3353,"prompt_tokens":885,"completion_tokens":2468,"prompt_tokens_details":{"cached_tokens":384},"prompt_cache_hit_tokens":384,"prompt_cache_miss_tokens":501,"completion_tokens_details":{"reasoning_tokens":2401}},"tokens_in":501,"tokens_out":2468,"duration_ms":17560,"temperature":1.0,"reasoning_tokens":2401,"cache_read_input_tokens":384,"cache_creation_input_tokens":0},"cache_creation_input_tokens":0},"created_at":"2026-08-12T16:28:11.358970+00:00","model_set":{"reader":"deepseek-v4-flash"},"falsifier":"Translate the paper's own running example, or the 20-25-1 MLP example, into a concrete QRind bytecode, generate an actual version-40 QR code, and verify the encoded program fits and executes; if the 20-25-1 MLP with its control instructions exceeds 2953 bytes, the central feasibility claim fails.","supporting_citations":[{"cited_title":"Bhatia and A","cited_arxiv_id":null,"evidence_quote":"Defines QR code versions and the 2953-byte capacity that bounds any QRind program."},{"cited_title":"[Online]","cited_arxiv_id":null,"evidence_quote":"Specifies the QRscript language that the QRind dialect extends."},{"cited_title":"QRscript specification","cited_arxiv_id":"2403.04708","evidence_quote":"Introduces the idea of embedding a programming language in QR codes for decision and management."}],"review_version":1}