{ "model": { "rank": 4303, "code": "thing-q175957", "model_id": "vr.tr.arduino", "name": "Arduino", "purpose": "Enable an AI agent to recognise an Arduino development board, assess its electrical and programming state, and determine which connections, firmware changes and operating actions are appropriate.", "family": "Thing Registry", "category": "Physical world and living systems", "status": "research-draft", "kind": "thing", "plane": "PHY", "domain": "PHY.OBJ", "industry": "", "version": "", "url": "/models/thing/q175957/", "tier": 2, "score": 76, "payload": { "layer": "wikidata", "aliases": [ "Arduino UNO", "Arduino Nano" ], "aliasCount": 2, "merged": 2, "knownIn": 76, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q175957", "url": "https://www.wikidata.org/wiki/Q175957", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T19:55:12Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 20.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: 01a087bc-1878-7f41-b90c-158c6ebdbb2c\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: Arduino\nSense to describe: (none recorded)\nDomain code: PHY.OBJ\nAlso known as: (none)\n\n\nContext for this batch of 695 things:\n# Batch 004: 1001 register", "usd": 0, "recall": true }, "codex": { "seconds": 66.2, "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: 01a087bc-188b-7c30-adf5-093e7f6af2e6\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: Arduino\nRegistry id: vr.tr.arduino\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\n\nContext " } } }, "metaModel": { "id": "THING-Q175957", "registryId": "vr.tr.arduino", "name": "Arduino", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q175957/", "model": { "registry_id": "vr.tr.arduino", "name": "Arduino", "purpose": "Enable an AI agent to recognise an Arduino development board, assess its electrical and programming state, and determine which connections, firmware changes and operating actions are appropriate.", "definition": "Arduino denotes an open-source electronics prototyping platform whose programmable development boards connect a processor to input/output interfaces for sensing and controlling physical systems; in this physical-object sense, the term covers the board family rather than the associated software or organisation.", "scope_statement": "This model owns Arduino in the PHY.OBJ sense: the kind of physical programmable development board associated with the Arduino platform, including the distinctions needed to assess particular board variants and units; the Arduino organisation, software tools and project ecosystem are related entities.", "in_scope": [ "Board identity, revision and relationship to an Arduino board design or compatible implementation", "Processor, memory and peripheral capabilities that constrain sketches and connected hardware", "Power inputs, logic levels, pin functions and electrical operating limits", "Boot, programming, firmware execution and communication states", "Shield and peripheral compatibility, physical condition and readiness for a proposed use" ], "out_of_scope": [ "Arduino as a company, trademark owner or community", "IDE, compiler, board-package and library internals, except their compatibility with the board", "Complete robots, instruments and other systems built around a board", "Sensors, actuators, shields and power supplies as independently modelled things", "Application source code and its intended behaviour, except its relationship to firmware installed on the board" ], "distinguishing_features": [ "Identify the specific board design from markings, layout and documentation; an Arduino name alone does not establish processor, pinout or electrical limits.", "Distinguish an official Arduino board from a third-party compatible board using documented manufacturer and product identity; compatibility does not establish official provenance.", "Distinguish a development board from a bare microcontroller by its board-level power, connection and programming facilities.", "Distinguish hardware identity from Arduino software support: being programmable through an Arduino toolchain does not by itself identify a board as an Arduino product.", "Treat a named board variant as a kind and its individual physical copy as a unit whose installed firmware, damage and modifications can differ." ], "characteristics": [ { "name": "Board design and revision", "kind": "category", "unit_or_values": "Documented product name, board identifier and hardware revision; unknown where unverified", "why_it_matters": "Determines which pinout, schematic, electrical limits and programming instructions apply." }, { "name": "Manufacturer and compatibility relationship", "kind": "relation", "unit_or_values": "Manufacturer; referenced Arduino design; official product, third-party compatible implementation or unresolved", "why_it_matters": "Separates provenance from electrical, mechanical and software compatibility." }, { "name": "Processor configuration", "kind": "category", "unit_or_values": "Processor part identifiers, architecture and roles of application, communication or auxiliary processors", "why_it_matters": "Constrains compilation targets, peripheral availability and recovery procedures." }, { "name": "Memory capacity", "kind": "measurement", "unit_or_values": "Bytes of program, volatile and nonvolatile storage, with reserved and usable amounts distinguished", "why_it_matters": "Helps judge whether a sketch and its runtime data can fit." }, { "name": "Power-input limits", "kind": "measurement", "unit_or_values": "V and A for each documented input path, with recommended operating ranges distinguished from absolute limits", "why_it_matters": "Supports selection of an appropriate supply and assessment of simultaneous power connections." }, { "name": "I/O electrical limits", "kind": "measurement", "unit_or_values": "Logic voltage and permitted input voltage in V; per-pin and aggregate current limits in mA", "why_it_matters": "Determines whether peripherals need level translation, buffering or separate drivers." }, { "name": "Pin and peripheral assignment", "kind": "relation", "unit_or_values": "Board-labelled pins mapped to processor functions, buses, shared resources and connected devices", "why_it_matters": "Exposes conflicts between GPIO, analogue input, communication and shield use." }, { "name": "Analogue and timing capability", "kind": "measurement", "unit_or_values": "ADC or DAC resolution in bits where present; reference voltage in V; clock and applicable PWM frequencies in Hz", "why_it_matters": "Constrains sensing precision and waveform generation without assuming identical capabilities across boards." }, { "name": "Firmware identity", "kind": "relation", "unit_or_values": "Installed image or build identifier linked to source, target configuration and upload evidence; unknown if unavailable", "why_it_matters": "Connects observed behaviour to a reproducible program." }, { "name": "Programming and execution state", "kind": "state", "unit_or_values": "Unpowered, booting, programming, executing, held in reset, fault suspected or unknown", "why_it_matters": "Determines which diagnostic and recovery actions are meaningful." }, { "name": "Mechanical interface", "kind": "measurement", "unit_or_values": "Board dimensions, mounting positions and connector geometry in mm", "why_it_matters": "Supports enclosure and shield fit checks independently of electrical compatibility." }, { "name": "Physical condition", "kind": "state", "unit_or_values": "Inspection observations for connectors, headers, solder joints, contamination, heating damage and modifications", "why_it_matters": "Determines whether documented capabilities remain plausible for the particular unit." } ], "affordances": [ "Identify the board variant and obtain its matching pinout, schematic and programming target.", "Check a proposed power supply, shield or peripheral connection against the board's documented limits.", "Select a compatible board package, upload route and firmware build.", "Read available diagnostics and observe execution without treating a successful upload as proof of correct application behaviour.", "Upload, reset or recover firmware while accounting for connected actuator behaviour and existing program preservation.", "Assess whether the board can support a proposed sensing, control or communication task." ] }, "sources": [], "structure": { "bundles": [ { "id": "board-identity-and-compatibility", "name": "Board identity and compatibility", "description": "Establish which physical Arduino board kind is represented and which documentation applies.", "rationale": "Arduino spans multiple board designs, and appearance or software support alone cannot establish their capabilities.", "layers": [ { "id": "design-identification", "name": "Design identification", "description": "Resolve product identity and hardware revision from physical and documentary evidence.", "findings": [ { "id": "board-design-evidence", "name": "Board design evidence", "description": "Record markings, processor identifiers, connector layout and the documentation they support, retaining uncertainty when these disagree.", "questions": [ { "text": "Which product and hardware revision match the board's markings, processor and connector layout?", "kind": "definition", "id": "board-design-evidence-q01" }, { "text": "Which manufacturer document or schematic supports that identification?", "kind": "provenance", "id": "board-design-evidence-q02" } ] } ] }, { "id": "compatibility-boundaries", "name": "Compatibility boundaries", "description": "Separate official product identity from compatibility with a design or toolchain.", "findings": [ { "id": "compatibility-dimensions", "name": "Compatibility dimensions", "description": "Assess mechanical fit, pin assignment, electrical behaviour and programming support separately.", "questions": [ { "text": "Is the board an official Arduino product, a documented compatible implementation or a board with Arduino software support only?", "kind": "boundary", "id": "compatibility-dimensions-q01" }, { "text": "Which claimed compatibility dimensions are documented, and which remain untested?", "kind": "provenance", "id": "compatibility-dimensions-q02" } ] } ] } ] }, { "id": "power-and-pin-electrics", "name": "Power and pin electrics", "description": "Describe permissible power paths and electrical interactions through the board's connectors.", "rationale": "A connection that physically fits can still exceed an Arduino variant's voltage or current limits.", "layers": [ { "id": "power-paths", "name": "Power paths", "description": "Identify supply entry points, regulation and interaction between attached supplies.", "findings": [ { "id": "supply-path-selection", "name": "Supply path selection", "description": "Record operating limits and protection behaviour for each available power input without assuming all boards share the same power-selection circuit.", "questions": [ { "text": "Which USB, connector or header paths may power this board, and what operating voltage and current constraints apply to each?", "kind": "measurement", "id": "supply-path-selection-q01" }, { "text": "May the proposed supplies be connected simultaneously, and what evidence establishes backfeed or power-selection behaviour?", "kind": "action", "id": "supply-path-selection-q02" } ] } ] }, { "id": "signal-electrical-limits", "name": "Signal electrical limits", "description": "Determine whether connected signals and loads are electrically compatible.", "findings": [ { "id": "pin-loading-and-levels", "name": "Pin loading and levels", "description": "Relate pin-specific voltage tolerance, current limits and grounding requirements to the proposed circuit.", "questions": [ { "text": "What input-voltage, output-current and aggregate current limits apply to the pins being used?", "kind": "measurement", "id": "pin-loading-and-levels-q01" }, { "text": "Which proposed connections require level translation, a driver, a shared reference or an independently powered load?", "kind": "action", "id": "pin-loading-and-levels-q02" } ] } ] } ] }, { "id": "sketch-execution-and-programming", "name": "Sketch execution and programming", "description": "Connect the board's processor and memory to its build, upload and execution lifecycle.", "rationale": "A sketch must match a specific target and upload route, and programming success does not establish application correctness.", "layers": [ { "id": "execution-target", "name": "Execution target", "description": "Establish the resources and software target needed to build a runnable image.", "findings": [ { "id": "target-and-resource-fit", "name": "Target and resource fit", "description": "Record processor architecture, available memory and target settings relevant to the proposed sketch.", "questions": [ { "text": "Which processor, board package and target settings correspond to this board revision?", "kind": "definition", "id": "target-and-resource-fit-q01" }, { "text": "How much program and runtime memory remains available after platform reservations and the proposed build?", "kind": "measurement", "id": "target-and-resource-fit-q02" } ] } ] }, { "id": "upload-and-recovery", "name": "Upload and recovery", "description": "Identify programming interfaces, installed firmware evidence and recovery options.", "findings": [ { "id": "firmware-transition-control", "name": "Firmware transition control", "description": "Describe how firmware can be identified, replaced and recovered, including reset behaviour and effects on connected outputs.", "questions": [ { "text": "What evidence identifies the installed firmware, bootloader where applicable and last successful upload?", "kind": "provenance", "id": "firmware-transition-control-q01" }, { "text": "Which upload or recovery procedure applies, and what must happen to connected loads before reset or reprogramming?", "kind": "action", "id": "firmware-transition-control-q02" } ] } ] } ] }, { "id": "pins-shields-and-peripherals", "name": "Pins, shields and peripherals", "description": "Represent how board resources are exposed and shared by connected hardware.", "rationale": "Arduino projects depend on pin mappings and expansion conventions whose details vary across designs.", "layers": [ { "id": "pin-function-allocation", "name": "Pin function allocation", "description": "Map board labels to available functions and shared processor resources.", "findings": [ { "id": "multiplexing-and-resource-conflicts", "name": "Multiplexing and resource conflicts", "description": "Track selected pin functions and dependencies between buses, timers, analogue functions and libraries.", "questions": [ { "text": "Which board-labelled pins provide the required GPIO, analogue, PWM and communication functions?", "kind": "definition", "id": "multiplexing-and-resource-conflicts-q01" }, { "text": "Do the selected libraries and peripherals compete for pins, timers, bus addresses or other shared resources?", "kind": "boundary", "id": "multiplexing-and-resource-conflicts-q02" } ] } ] }, { "id": "expansion-fit", "name": "Expansion fit", "description": "Check shields and modules against the particular board's physical and functional interfaces.", "findings": [ { "id": "shield-and-module-matching", "name": "Shield and module matching", "description": "Assess connector alignment, pin usage, supply demand and software support as distinct requirements.", "questions": [ { "text": "Do the proposed shield's connector geometry and pin assignments match this board revision?", "kind": "measurement", "id": "shield-and-module-matching-q01" }, { "text": "What adaptations are required for the shield or module to operate within the board's electrical and software constraints?", "kind": "action", "id": "shield-and-module-matching-q02" } ] } ] } ] }, { "id": "condition-diagnostics-and-use-readiness", "name": "Condition, diagnostics and use readiness", "description": "Assess whether a particular board can perform a proposed task and how faults can be isolated.", "rationale": "Documented board capabilities do not establish the condition of a unit or the behaviour of its attached circuit.", "layers": [ { "id": "board-fault-isolation", "name": "Board fault isolation", "description": "Interpret observations across power, host connection, upload and application execution.", "findings": [ { "id": "diagnostic-evidence", "name": "Diagnostic evidence", "description": "Use physical inspection, supply measurements and interface observations to narrow faults without assuming every board exposes the same indicators.", "questions": [ { "text": "What do inspection, supply-rail measurements and available indicators reveal about the board's present state?", "kind": "measurement", "id": "diagnostic-evidence-q01" }, { "text": "Which checks can distinguish a cable or host-interface problem from a boot, firmware or attached-circuit fault?", "kind": "action", "id": "diagnostic-evidence-q02" } ] } ] }, { "id": "application-readiness", "name": "Application readiness", "description": "Relate observed operation and documented limits to the intended deployment.", "findings": [ { "id": "readiness-and-system-boundary", "name": "Readiness and system boundary", "description": "Record evidence for required sensing, timing and output behaviour while assigning enclosure, load protection and system-level compliance to the assembled system.", "questions": [ { "text": "Which observations demonstrate that the installed sketch meets the proposed task's timing, sensing and output requirements?", "kind": "measurement", "id": "readiness-and-system-boundary-q01" }, { "text": "Which environmental limits and product approvals apply to the bare board, and which requirements must be assessed for the completed assembly?", "kind": "boundary", "id": "readiness-and-system-boundary-q02" } ] } ] } ] }, { "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": [ "The recorded name is ambiguous between the platform, organisation and hardware; this description selects the hardware-family sense suggested by PHY.OBJ.", "Electrical limits, dimensions, processors and connectivity vary substantially by model and revision; the measurements given are explicitly scoped examples.", "No sources were consulted. Applicable conformity requirements and certification claims require verification for the exact board and destination market." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of Arduino 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": [ "Uno boards", "Nano boards", "Mega boards", "MKR boards", "Due boards", "Portenta boards" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of Arduino 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": "Arduino board model and revision", "value_or_pattern": "Arduino Uno Rev3", "note": "Identifies a board design and revision, not an individual physical unit." }, { "scheme": "Arduino Fully Qualified Board Name (FQBN)", "value_or_pattern": "arduino:avr:uno", "note": "Identifies a software build target for the Uno in the Arduino AVR Boards package; it is not a hardware serial number." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of Arduino 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": [ "Teaching programming, electronics and embedded systems", "Prototyping sensor acquisition and data logging", "Controlling robots through external motor drivers", "Building interactive installations and physical user interfaces", "Prototyping connected monitoring and automation devices" ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of Arduino 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": "Digital logic voltage", "typical_range": "3.3 or 5, depending on board; input tolerance must be checked separately", "unit": "V" }, { "quantity": "Processor clock frequency", "typical_range": "16 for Uno Rev3 and Mega 2560 Rev3; 84 for Due", "unit": "MHz" }, { "quantity": "Uno Rev3 board outline", "typical_range": "68.6 × 53.4", "unit": "mm" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of Arduino 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": [ "Overvoltage, reversed polarity or incorrect power connections can damage the board.", "Applying 5 V signals to inputs that are not 5 V tolerant can damage 3.3 V boards.", "Driving motors, relays or other substantial loads directly from input/output pins can exceed electrical limits.", "Inductive voltage transients, electrostatic discharge and short circuits can damage components or cause resets.", "Software faults or brownouts can produce unintended actuator behaviour; safety-critical control requires independent protective measures." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of Arduino 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": "Microcontroller", "difference": "A microcontroller is an integrated circuit; an Arduino board packages a processor with supporting circuitry, connectors and a development ecosystem." }, { "name": "Arduino IDE", "difference": "The IDE is software used to develop and upload programs, rather than a physical development board." }, { "name": "Arduino-compatible board", "difference": "Compatibility describes support for some Arduino interfaces or software; it does not establish that a board is an official Arduino product." }, { "name": "Shield", "difference": "A shield is an expansion board that adds functions to a compatible host board." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of Arduino this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does vr.tr.arduino intend official Arduino hardware only, or also third-party compatible boards? The PHY.OBJ placement supports a board-focused interpretation but does not settle membership.", "Does an existing Vercy world model already cover this board concept, requiring this registry entry to link to that model?", "Which board families and revisions must the initial researched model cover, and which manufacturer documents establish their differing electrical and programming requirements?", "How should hardware with Arduino toolchain support but no claim to Arduino board identity relate to this entry?", "Which board-specific environmental ratings, conformity declarations and recovery procedures can be verified from primary documentation?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 17, "questions": 27 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "unclassified", "method": "Written from the archetype playbook - what this kind of thing needs beyond identity and provenance - and from the structure that recurred across 6,333 models already researched by two engines. Applied to this entry by rule. No source was read for this thing and no claim here is researched. This entry carries no facets of its own, so they were inferred from its domain - a guess about a whole domain applied to one thing.", "facetsInferred": true, "nextPass": "A researcher replaces this draft with a sourced specification. Treat every sentence below as a proposal to argue with.", "purpose": "Give an agent a durable, checkable way to recognise a Arduino, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise an Arduino development board, assess its electrical and programming state, and determine which connections, firmware changes and operating actions are appropriate.", "characteristics": { "substance": "material", "origin": "manufactured", "agency": "inert", "mobility": "varies" }, "whatYouCanDoWithIt": [ "observed and measured" ], "distinguishingFeatures": [ "Names folded into this entry, which a task may need to split apart again: Arduino UNO, Arduino Nano.", "2 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 76 Wikipedia languages, which is a measure of how widely the thing is known, not of how important it is." ], "openQuestionsForResearch": [ "Which of the bundles below does a real task actually need, and which are ceremony?", "What does this thing have that the facets do not capture at all?", "Which neighbouring kind is most often confused with a Arduino, and on what evidence are they told apart?" ], "whatItIsMadeOf": "matter you can touch", "physicalCharacter": [ "Mobility varies between examples.", "Does nothing on its own; everything it does, something else did to it.", "These come from the domain this entry sits in rather than from the entry itself, so treat them as a first guess about the whole domain applied to one thing." ], "whatCanBeDoneWithIt": [ "observe it, measure it, record its state" ], "howItIsRecognised": [ "Recognised by form and material. The registry holds no appearance data, so what a Arduino looks like has to come from research." ], "relatedModels": [ { "relation": "covers", "note": "Finer kinds folded into this entry because telling them apart needs a task that asks for it. Each is a model waiting to be split out when one does.", "targets": [ "Arduino UNO", "Arduino Nano" ] } ], "standing": "Described in 76 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 2 finer distinctions are held inside this entry as names rather than as separate models.", "structure": { "bundles": [ { "id": "identity-and-classification", "name": "Identity, naming and classification", "description": "How an agent tells one Arduino from another, and a Arduino from things that resemble it.", "rationale": "Recognition comes before every other claim. Without stable identity nothing else in the model can be trusted to be about the same thing twice.", "layers": [ { "id": "naming-and-identifiers", "name": "Names and identifiers", "description": "The names this thing goes by and the identifiers that survive translation and time.", "findings": [ { "id": "preferred-name-and-aliases", "name": "Preferred name, aliases and local names", "description": "Which name to use, which names mean the same thing, and which merely sound similar.", "questions": [ { "id": "preferred-name-and-aliases-q01", "text": "What identifies and describes the name of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "preferred-name-and-aliases-q02", "text": "Who or what asserted this about the name of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "preferred-name-and-aliases-q03", "text": "What may an agent decide or do once the name of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "stable-identifiers", "name": "Stable identifiers and external keys", "description": "Identifiers that keep pointing at this kind of thing across systems and languages.", "questions": [ { "id": "stable-identifiers-q01", "text": "What identifies and describes an identifier for a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stable-identifiers-q02", "text": "Who or what asserted this about an identifier for a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stable-identifiers-q03", "text": "What may an agent decide or do once an identifier for a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "classification-and-granularity", "name": "Classification and granularity", "description": "Where a Arduino sits among kinds, and how finely a task needs to cut it.", "findings": [ { "id": "kind-and-parents", "name": "Kind, parents and neighbouring kinds", "description": "The classes this thing belongs to and the ones it is next to.", "questions": [ { "id": "kind-and-parents-q01", "text": "What identifies and describes the kind of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "kind-and-parents-q02", "text": "Who or what asserted this about the kind of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "kind-and-parents-q03", "text": "What may an agent decide or do once the kind of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] }, { "id": "distinguishing-features", "name": "Distinguishing features", "description": "What separates a Arduino from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "distinguishing-features-q02", "text": "Who or what asserted this about what distinguishes a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "distinguishing-features-q03", "text": "What may an agent decide or do once what distinguishes a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "form-and-composition", "name": "Form, composition and condition", "description": "What a Arduino is made of, what shape and size it takes, and what state it is in.", "rationale": "A physical thing can be measured, and a model that cannot record its measurements cannot support any decision that depends on them.", "layers": [ { "id": "form-and-dimensions", "name": "Form and dimensions", "description": "Shape, size, mass and the ranges these take across examples.", "findings": [ { "id": "measurable-dimensions", "name": "Measurable dimensions and their units", "description": "The quantities worth recording and the units they are recorded in.", "questions": [ { "id": "measurable-dimensions-q01", "text": "What identifies and describes the dimensions of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "measurable-dimensions-q02", "text": "Who or what asserted this about the dimensions of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "measurable-dimensions-q03", "text": "What may an agent decide or do once the dimensions of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "material-and-composition", "name": "Material and composition", "description": "Materials, parts and how they are put together.", "findings": [ { "id": "parts-and-materials", "name": "Parts and materials", "description": "What a Arduino is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "parts-and-materials-q02", "text": "Who or what asserted this about the composition of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "parts-and-materials-q03", "text": "What may an agent decide or do once the composition of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "condition-and-integrity", "name": "Condition and integrity", "description": "Wear, damage, health and the difference between working and broken.", "findings": [ { "id": "condition-assessment", "name": "Condition, damage and health", "description": "How the condition of a Arduino is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "condition-assessment-q02", "text": "Who or what asserted this about the condition of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "condition-assessment-q03", "text": "What may an agent decide or do once the condition of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "place-and-movement", "name": "Place and movement", "description": "Where a Arduino is, how it got there and where it may go (varies).", "rationale": "A thing that can move needs its position recorded with a time, or every later claim about it is about a place it has left.", "layers": [ { "id": "location-and-placement", "name": "Location and placement", "description": "Position, containment and the reference frame the position is given in.", "findings": [ { "id": "position-and-frame", "name": "Position, container and reference frame", "description": "Where a Arduino is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "position-and-frame-q02", "text": "Who or what asserted this about the location of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "position-and-frame-q03", "text": "What may an agent decide or do once the location of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "movement-and-transfer", "name": "Movement and transfer", "description": "How a Arduino is carried, installed or relocated.", "findings": [ { "id": "movement-events", "name": "Movement events and constraints", "description": "What counts as a movement, what records it and what limits it.", "questions": [ { "id": "movement-events-q01", "text": "What identifies and describes the movement of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "movement-events-q02", "text": "Who or what asserted this about the movement of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "movement-events-q03", "text": "What may an agent decide or do once the movement of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "state-and-lifecycle", "name": "State and lifecycle", "description": "The states a Arduino passes through and the events that move it between them.", "rationale": "Most decisions about a thing depend on what state it is in now, which is a claim with a time on it, not a property.", "layers": [ { "id": "lifecycle-stages", "name": "Lifecycle stages", "description": "From coming into existence to ceasing to be one of these.", "findings": [ { "id": "stages-and-transitions", "name": "Stages and transitions", "description": "The stages worth naming and what moves a Arduino between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "stages-and-transitions-q02", "text": "Who or what asserted this about the lifecycle of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "stages-and-transitions-q03", "text": "What may an agent decide or do once the lifecycle of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "observations-and-status", "name": "Observations and current status", "description": "What is observed about a Arduino, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a Arduino is recorded so that it can be superseded rather than overwritten.", "questions": [ { "id": "observation-record-q01", "text": "What identifies and describes an observation of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "observation-record-q02", "text": "Who or what asserted this about an observation of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "observation-record-q03", "text": "What may an agent decide or do once an observation of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "use-and-operation", "name": "Use and operation", "description": "What can be done with a Arduino and what it takes to do it.", "rationale": "An agent that can recognise a thing but not act on it has only half a model.", "layers": [ { "id": "intended-use", "name": "Intended use and function", "description": "What a Arduino is for, and what it is used for anyway.", "findings": [ { "id": "function-and-purpose", "name": "Function, purpose and misuse", "description": "The function a Arduino performs and the uses that fall outside it.", "questions": [ { "id": "function-and-purpose-q01", "text": "What identifies and describes the use of a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "function-and-purpose-q02", "text": "Who or what asserted this about the use of a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "function-and-purpose-q03", "text": "What may an agent decide or do once the use of a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "handling-and-procedure", "name": "Handling and procedure", "description": "The steps, skills and tools involved in using a Arduino.", "findings": [ { "id": "procedures-and-skills", "name": "Procedures, skills and required tools", "description": "What an agent needs before it can act on a Arduino at all.", "questions": [ { "id": "procedures-and-skills-q01", "text": "What identifies and describes handling a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "procedures-and-skills-q02", "text": "Who or what asserted this about handling a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "procedures-and-skills-q03", "text": "What may an agent decide or do once handling a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a Arduino came from and when it held.", "rationale": "A claim without a source and a time cannot be superseded, only overwritten, and an agent that overwrites loses the ability to explain itself.", "layers": [ { "id": "source-and-authority", "name": "Source and authority", "description": "Who said it, on what evidence, and how strongly.", "findings": [ { "id": "claim-provenance", "name": "Claim provenance and confidence", "description": "The authority behind each claim about a Arduino and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "claim-provenance-q02", "text": "Who or what asserted this about a claim about a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "claim-provenance-q03", "text": "What may an agent decide or do once a claim about a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] }, { "id": "time-and-versions", "name": "Time, versions and supersession", "description": "When a claim was true, when it was learnt, and what replaced it.", "findings": [ { "id": "validity-and-supersession", "name": "Validity period and supersession", "description": "How an old claim about a Arduino is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a Arduino, and in what units or vocabulary?", "kind": "definition", "answer_data": [ "identifiers", "types and classes", "values with units", "explicit unknowns" ] }, { "id": "validity-and-supersession-q02", "text": "Who or what asserted this about the validity of a claim about a Arduino, by which method, and when was it true?", "kind": "provenance", "answer_data": [ "authority", "method", "evidence", "event time", "knowledge time" ] }, { "id": "validity-and-supersession-q03", "text": "What may an agent decide or do once the validity of a claim about a Arduino is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 6, "layers": 13, "findings": 15, "questions": 45 } } } }