{ "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-12T11:37:06Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 24.8, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09567-03fa-7b33-9cb0-8dfa6d72867e\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: NodeMCU\nSense to describe: (none recorded)\nDomain code: PHY.OBJ\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Batch 044: 1001 registe", "usd": 0.0, "recall": true }, "codex": { "seconds": 74.8, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a09567-03fe-7f51-a12b-eca151f50be1\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: NodeMCU\nRegistry id: vr.tr.nodemcu\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\n\nContext " } }, "enrichment": { "pass": 3, "engine": "claude", "producedAt": "2026-10-06T12:00:00Z", "ingestedAt": "2026-10-06T08:56:51+00:00", "fields": [ "agent_conduct", "ethics", "failure_modes_and_hazards", "owners", "standards_and_regulation", "visual_identification" ] }, "revisions": [ { "at": "2026-10-07T11:22:46+00:00", "engine": "codex", "fields": [ "agent_conduct", "definition", "distinguishing_features", "ethics", "in_scope", "out_of_scope", "owners", "purpose", "scope_statement", "visual_identification" ], "answering_review": "df757add96a3793031cf053030f75ebc293e1df358bd701cb0d878c6db629798" } ], "gate": { "passed": true, "version": "1.0", "at": "2026-10-07T12:16:30+00:00", "evidence": [ "completeness 1.00", "sense: Wikidata description", "2 live sources", "review by codex: pass" ] } }, "metaModel": { "id": "THING-Q19729219", "registryId": "vr.tr.nodemcu", "name": "NodeMCU", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q19729219/", "model": { "registry_id": "vr.tr.nodemcu", "name": "NodeMCU", "purpose": "Enable an agent to recognise the NodeMCU platform, distinguish its firmware and hardware components, and assess compatibility, operating state and authorised use.", "definition": "NodeMCU is an open-source IoT platform using the Lua scripting language, comprising firmware for supported microcontrollers and associated development hardware.", "scope_statement": "This model covers NodeMCU as an open-source Lua-based IoT platform, including its firmware, supported hardware relationships and development capabilities.", "in_scope": [ "Platform identity includes its open-source firmware and associated development hardware.", "Firmware versions, Lua capabilities and supported interfaces determine application compatibility.", "Hardware support and board-specific constraints govern platform deployment.", "Boot, programming, execution and recovery capabilities depend on the firmware and hardware combination.", "Security, wireless operation and readiness are assessed for the proposed application." ], "out_of_scope": [ "Processor families as standalone semiconductor kinds are outside this model.", "Generic development boards without an established relationship to the platform are outside this model.", "Application logic, cloud services and network infrastructure are separate models.", "External sensors, actuators, power supplies and finished IoT products are separate entities.", "Ownership and maintenance history of individual devices are included only where needed to assess platform deployment." ], "distinguishing_features": [ "Lua scripting is a defining capability of the platform's firmware.", "The platform includes firmware and associated development hardware, so a board alone does not define its identity.", "Firmware identity and hardware compatibility require separate evidence.", "A Wi-Fi-capable microcontroller or a NodeMCU-labelled board does not by itself establish that NodeMCU firmware is installed.", "Supported capabilities depend on the firmware version, build and hardware configuration." ], "characteristics": [ { "name": "Hardware identity", "kind": "category", "unit_or_values": "Documented design, revision, manufacturer and compatibility evidence; unresolved permitted", "why_it_matters": "Determines which schematic, pinout and limits apply." }, { "name": "Processor and radio module", "kind": "relation", "unit_or_values": "Link to identified SoC and module part numbers", "why_it_matters": "Constrains firmware targets, radio capabilities and peripheral availability." }, { "name": "Flash capacity and layout", "kind": "measurement", "unit_or_values": "Bytes of detected flash; byte offsets and sizes of firmware regions", "why_it_matters": "Prevents choosing an incompatible image or overwriting retained data." }, { "name": "Power-input envelope", "kind": "measurement", "unit_or_values": "V and mA for each verified input path and operating condition", "why_it_matters": "Supports selection of a supply and assessment of startup or radio-load instability." }, { "name": "Signal and analogue-input limits", "kind": "measurement", "unit_or_values": "V and mA by header pin, including any verified input divider", "why_it_matters": "Board-input limits must be established separately from bare-chip limits." }, { "name": "Header-to-processor mapping", "kind": "relation", "unit_or_values": "Printed pin label to processor GPIO, alternate function and boot constraint", "why_it_matters": "Prevents confusing board labels with processor pin identifiers." }, { "name": "Programming interface", "kind": "category", "unit_or_values": "Identified USB bridge or serial interface, connector and reset-control arrangement", "why_it_matters": "Determines host connectivity and how to enter the firmware loader." }, { "name": "Execution state", "kind": "state", "unit_or_values": "Unpowered, booting, loader, running, sleeping, reset loop or unknown", "why_it_matters": "Determines whether to observe, wake, reset or recover the board." }, { "name": "Installed firmware", "kind": "relation", "unit_or_values": "Firmware project, build identifier, target and image digest where available", "why_it_matters": "Hardware branding does not establish the available programming environment." }, { "name": "Integration geometry", "kind": "measurement", "unit_or_values": "Board dimensions, header pitch, row spacing and clearance in mm", "why_it_matters": "Determines fit in a breadboard, carrier or enclosure." } ], "affordances": [ "Identify a board variant and select its corresponding schematic, pinout and programming target.", "Assess a proposed power source and peripheral wiring against verified board limits.", "Read diagnostic output and distinguish loader, application, sleep and fault states.", "Back up recoverable contents, select a compatible firmware image and execute a supported flashing procedure.", "Configure exposed interfaces and wireless operation within the identified hardware and firmware capabilities.", "Diagnose power, connection, boot or radio faults and determine whether recovery or replacement is appropriate." ], "agent_conduct": { "may": [ "Identify NodeMCU firmware and associated development hardware from documented evidence.", "Flash firmware the owner has approved onto a board the agent is authorized to manage.", "Report firmware versions and known vulnerabilities to the owner." ], "must_not": [ "Deploy it to connect to networks or devices without the owner's permission.", "Use it to capture, jam or interfere with other people's wireless traffic.", "Ship devices with default credentials or unpatched firmware.", "Control mains-voltage loads from it without proper isolation and protection." ], "requires_human": [ "Connecting a platform deployment to equipment that affects safety or people's homes requires human approval.", "Deploying the platform on networks shared with others requires human approval." ] }, "ethics": { "considerations": [ "Insecure platform deployments can expose connected devices and other network users to misuse.", "Home sensors built with the platform can collect private data about occupants." ], "affected_parties": [ "Owners and users are affected by platform security.", "Occupants of monitored spaces are affected by data collection.", "Other network users can be affected by insecure deployments." ] }, "owners": { "steward": "Project maintainers steward platform development, while deployment owners are responsible for their installations.", "master_systems": [] }, "visual_identification": [ "Physical appearance alone cannot establish platform or installed firmware identity.", "Board markings and layouts can support identification of associated development hardware.", "Firmware records and version information provide evidence beyond the board's appearance." ], "failure_modes_and_hazards": [ "Insecure firmware turning devices into entry points for attacks.", "Overheating or shorts from wiring errors.", "Shock and fire risk when used to switch mains power improperly." ], "standards_and_regulation": [ "Radio Equipment Directive 2014/53/EU, European Union." ], "what_it_is_for": [ "These development boards are used in embedded prototyping to connect sensors, actuators and other circuits to wireless networks.", "They are encountered in teaching laboratories, hobby projects and experimental monitoring systems where scripts control input and output." ] }, "sources": [ { "id": "wikidata", "title": "Wikidata item Q19729219: NodeMCU", "url": "https://www.wikidata.org/wiki/Q19729219", "url_status": "live", "what_it_supports": "identity and sense of the item", "checked_by": "wikidata-api" }, { "id": "wikipedia-en", "title": "Wikipedia: NodeMCU", "url": "https://en.wikipedia.org/wiki/NodeMCU", "url_status": "live", "what_it_supports": "general description of the item", "checked_by": "wikidata-api sitelink" } ], "structure": { "bundles": [ { "id": "board-identity-and-lineage", "name": "Board identity and lineage", "description": "Establish which physical hardware the NodeMCU name denotes.", "rationale": "The registry has no definition, and the project name spans hardware and firmware.", "layers": [ { "id": "registry-boundary", "name": "Registry boundary", "description": "Separate the physical board kind from related software and platform concepts.", "findings": [ { "id": "hardware-sense", "name": "Hardware sense", "description": "Record evidence supporting the provisional development-board interpretation.", "questions": [ { "text": "Does the registry's originating record denote development boards, firmware or the combined project?", "kind": "boundary", "id": "hardware-sense-q01" }, { "text": "Which existing Vercy model, if any, already owns this same concept?", "kind": "boundary", "id": "hardware-sense-q02" } ] } ] }, { "id": "variant-resolution", "name": "Variant resolution", "description": "Resolve the board to a supported hardware reference.", "findings": [ { "id": "design-evidence", "name": "Design evidence", "description": "Associate observed markings and components with a specific design rather than trusting a sales name.", "questions": [ { "text": "Which revision markings, module identifier and board-layout features are observable?", "kind": "measurement", "id": "design-evidence-q01" }, { "text": "Which schematic or manufacturer record supports the claimed revision and compatibility?", "kind": "provenance", "id": "design-evidence-q02" } ] } ] } ] }, { "id": "power-and-electrical-envelope", "name": "Power and electrical envelope", "description": "Determine how the identified board may be powered and connected.", "rationale": "Power labels and chip specifications alone do not establish the limits of an assembled variant.", "layers": [ { "id": "supply-paths", "name": "Supply paths", "description": "Identify input paths, regulation and interactions between supplies.", "findings": [ { "id": "input-path-compatibility", "name": "Input-path compatibility", "description": "Establish allowable supply conditions from the actual power circuit.", "questions": [ { "text": "What voltage and current envelope applies to USB and each exposed power pin on this revision?", "kind": "measurement", "id": "input-path-compatibility-q01" }, { "text": "Does the circuit permit simultaneous USB and external power without backfeeding?", "kind": "action", "id": "input-path-compatibility-q02" }, { "text": "What protection or isolation components are present in the documented supply paths?", "kind": "provenance", "id": "input-path-compatibility-q03" } ] } ] }, { "id": "signal-limits", "name": "Signal limits", "description": "Resolve permissible voltages and loads at the exposed headers.", "findings": [ { "id": "header-electrical-limits", "name": "Header electrical limits", "description": "Distinguish processor limits from limits modified by board circuitry.", "questions": [ { "text": "What input-voltage and output-current limits apply to each intended digital connection?", "kind": "measurement", "id": "header-electrical-limits-q01" }, { "text": "Does the analogue input include a divider, and what verified header-voltage range follows from it?", "kind": "measurement", "id": "header-electrical-limits-q02" }, { "text": "Which proposed peripherals require level conversion or a separate load driver?", "kind": "action", "id": "header-electrical-limits-q03" } ] } ] } ] }, { "id": "headers-and-physical-integration", "name": "Headers and physical integration", "description": "Relate software-visible pins to physical connections and installation constraints.", "rationale": "A matching processor does not guarantee compatible pin labels, boot behavior or footprint.", "layers": [ { "id": "pin-resolution", "name": "Pin resolution", "description": "Translate printed labels into usable processor functions.", "findings": [ { "id": "label-function-and-boot-mapping", "name": "Label, function and boot mapping", "description": "Record pin aliases together with startup constraints and on-board sharing.", "questions": [ { "text": "Which processor GPIO corresponds to each printed header label in the selected software environment?", "kind": "definition", "id": "label-function-and-boot-mapping-q01" }, { "text": "Which exposed pins affect boot selection or share connections with flash, LEDs or programming circuitry?", "kind": "boundary", "id": "label-function-and-boot-mapping-q02" }, { "text": "Will the proposed peripheral hold any startup-sensitive pin at an incompatible level during reset?", "kind": "action", "id": "label-function-and-boot-mapping-q03" } ] } ] }, { "id": "mechanical-fit", "name": "Mechanical fit", "description": "Determine whether a board can be installed without obstructing connections or the antenna.", "findings": [ { "id": "carrier-and-enclosure-fit", "name": "Carrier and enclosure fit", "description": "Assess the actual footprint and required access.", "questions": [ { "text": "What are the measured board dimensions, header spacing and connector overhang?", "kind": "measurement", "id": "carrier-and-enclosure-fit-q01" }, { "text": "Does the proposed carrier or enclosure preserve access to USB, reset controls and required header contacts?", "kind": "action", "id": "carrier-and-enclosure-fit-q02" }, { "text": "What antenna-clearance requirements does the identified module documentation specify?", "kind": "provenance", "id": "carrier-and-enclosure-fit-q03" } ] } ] } ] }, { "id": "firmware-boot-and-recovery", "name": "Firmware, boot and recovery", "description": "Determine what runs on the board and how execution can be changed or restored.", "rationale": "Board identity, installed runtime and programming-tool configuration must be established separately.", "layers": [ { "id": "image-compatibility", "name": "Image compatibility", "description": "Relate firmware requirements to detected hardware resources.", "findings": [ { "id": "firmware-target-and-storage", "name": "Firmware target and storage", "description": "Establish a compatible image and preserve data that a reflash would overwrite.", "questions": [ { "text": "What firmware and build are installed, and what evidence identifies them?", "kind": "provenance", "id": "firmware-target-and-storage-q01" }, { "text": "What processor target, detected flash capacity and storage layout must a replacement image match?", "kind": "measurement", "id": "firmware-target-and-storage-q02" }, { "text": "Which firmware regions or configuration data should be backed up before programming?", "kind": "action", "id": "firmware-target-and-storage-q03" } ] } ] }, { "id": "loader-and-reset-control", "name": "Loader and reset control", "description": "Establish the variant-specific route into normal execution and firmware loading.", "findings": [ { "id": "programming-path", "name": "Programming path", "description": "Use verified USB, serial and reset arrangements to diagnose or recover execution.", "questions": [ { "text": "Which USB-to-serial device, host driver and serial settings apply to this board?", "kind": "definition", "id": "programming-path-q01" }, { "text": "What button sequence or host-controlled reset sequence enters the loader on this revision?", "kind": "action", "id": "programming-path-q02" }, { "text": "What observed output distinguishes successful boot, loader entry and repeated reset?", "kind": "measurement", "id": "programming-path-q03" } ] } ] } ] }, { "id": "wireless-operation-and-serviceability", "name": "Wireless operation and serviceability", "description": "Assess network readiness and practical fault recovery in the intended installation.", "rationale": "A programmable board can still fail its intended role because of radio conditions, unstable power or unrecoverable faults.", "layers": [ { "id": "radio-and-network-readiness", "name": "Radio and network readiness", "description": "Establish usable wireless capabilities for the identified module and installed firmware.", "findings": [ { "id": "supported-wireless-operation", "name": "Supported wireless operation", "description": "Keep hardware capability, firmware support and observed connectivity distinct.", "questions": [ { "text": "Which bands, network modes and authentication methods are documented for this module and firmware combination?", "kind": "provenance", "id": "supported-wireless-operation-q01" }, { "text": "What signal level, connection stability and reconnection behavior are observed at the intended location?", "kind": "measurement", "id": "supported-wireless-operation-q02" }, { "text": "Which radio approval identifiers and integration conditions are documented, and which issuing bodies or authorities do they reference?", "kind": "provenance", "id": "supported-wireless-operation-q03" } ] } ] }, { "id": "fault-isolation-and-return-to-service", "name": "Fault isolation and return to service", "description": "Separate board faults from supply, cable, wiring and firmware faults.", "findings": [ { "id": "recoverability-evidence", "name": "Recoverability evidence", "description": "Base repair, reflash or replacement decisions on repeatable observations.", "questions": [ { "text": "Do resets coincide with supply-voltage dips, peripheral attachment or radio activity?", "kind": "measurement", "id": "recoverability-evidence-q01" }, { "text": "Which checks isolate a data-cable or USB-interface problem from processor boot failure?", "kind": "action", "id": "recoverability-evidence-q02" }, { "text": "What successful programming, execution, I/O and connectivity checks are required before returning this board to its intended role?", "kind": "action", "id": "recoverability-evidence-q03" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "NodeMCU is ambiguous between firmware and hardware; PHY.OBJ supports the board-family interpretation.", "The quantitative details primarily describe common ESP8266 boards and should not be transferred to ESP32-based products.", "Check the specific board revision for flash size, analog-input scaling, power-input limits, pin mapping and regulatory certification; the NodeMCU name alone does not establish them." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Original ESP8266 NodeMCU DevKit", "ESP8266 NodeMCU DevKit v1.0", "Third-party ESP8266 NodeMCU-compatible boards", "ESP32-based boards marketed as NodeMCU" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "scheme": "NodeMCU hardware design revision", "value_or_pattern": "DevKit v0.9; DevKit v1.0", "note": "Design revisions distinguish board layouts; third-party version labels are not consistently equivalent." }, { "scheme": "Espressif chip and module designations", "value_or_pattern": "ESP8266EX; ESP-12E; ESP-12F", "note": "These identify a chip or fitted module, not the complete NodeMCU board; inspect the particular board." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "IEEE 802.11 b/g/n, issued by IEEE: wireless networking standards supported by the ESP8266 radio." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Prototyping Wi-Fi-connected sensors and data loggers.", "Home-automation interfaces and controllers.", "Embedded-programming and Internet of Things education.", "Network-controlled actuators through suitable external driver circuits.", "Experiments using Lua firmware or other compatible embedded development environments." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "quantity": "Logic and chip supply voltage", "typical_range": "3.3 nominal", "unit": "V" }, { "quantity": "USB input voltage on commonly encountered boards", "typical_range": "5 nominal", "unit": "V" }, { "quantity": "ESP8266 CPU clock frequency", "typical_range": "80 or 160", "unit": "MHz" }, { "quantity": "External flash capacity on common ESP8266 boards", "typical_range": "4 commonly fitted; board-dependent", "unit": "MB" }, { "quantity": "ESP8266 Wi-Fi operating band", "typical_range": "2.4", "unit": "GHz" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Unstable power during radio transmission can cause resets and unreliable operation.", "Applying 5 V to 3.3 V GPIO pins can damage the chip.", "External circuitry that drives boot-strapping pins incorrectly can prevent normal startup or flashing.", "Connecting motors, relays or other substantial loads directly to GPIO can cause overcurrent damage; inductive loads require appropriate suppression.", "Confusing board pin labels with GPIO numbers, or assuming an analog-input voltage range from another board revision, can cause wiring errors or damage." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Permitted Wi-Fi channels and radio operating conditions vary by regulatory jurisdiction.", "Locally sold boards may use different USB-to-serial chips, regulators, dimensions and marketing version labels." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "name": "NodeMCU firmware", "difference": "The firmware is a Lua-based software project; the physical development board can run it or other compatible firmware." }, { "name": "ESP8266", "difference": "ESP8266 names the underlying system-on-chip family; a NodeMCU board adds a module or chip implementation, connectors and supporting circuitry." }, { "name": "ESP-12E or ESP-12F module", "difference": "These are radio modules used on many NodeMCU boards, rather than complete USB development boards." }, { "name": "WeMos D1 mini", "difference": "This is a distinct development-board family with its own layout and accessory ecosystem, despite overlapping ESP8266 capabilities." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of NodeMCU this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the originating registry record intend NodeMCU firmware, its development-board family or the combined project, and is the current PHY placement authoritative?", "Which official revisions and third-party NodeMCU-labelled boards belong within this entry, particularly products using different processor families?", "Does an existing world model already cover the intended NodeMCU concept and therefore require linking instead of a separate publication?", "What revision-specific evidence establishes power-input limits, analogue-input scaling, pin mappings, dimensions and protection circuitry?", "Which manufacturer records substantiate radio approvals, integration conditions and recovery procedures for the variants admitted to scope?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 19, "questions": 37 } }