{ "model": { "rank": 3058, "code": "thing-q42378", "model_id": "vr.tr.usb", "name": "USB", "purpose": "Enable an AI agent to recognise a physical USB connection or interface, assess its compatibility and condition, and decide whether and how it may safely connect devices, transfer data or deliver power.", "family": "Thing Registry", "category": "Physical world and living systems", "status": "research-draft", "kind": "thing", "plane": "PHY", "domain": "PHY.OBJ", "industry": "", "version": "", "url": "/models/thing/q42378/", "tier": 2, "score": 92, "payload": { "layer": "wikidata", "aliases": [ "HID++", "USB On-The-Go", "USB standard connector adapter", "USB condom", "USB 2 connector adapter" ], "aliasCount": 5, "merged": 5, "knownIn": 92, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q42378", "url": "https://www.wikidata.org/wiki/Q42378", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T14:30:53Z", "providers": [ "Codex", "Grok" ], "missingProviders": [], "pass": 2, "cost": { "grok": { "usd": 0.01375946, "turns": 1, "seconds": 154.8, "error": null }, "codex": { "seconds": 75.4, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.3\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: 01a07c42-b0d3-75a0-ba83-d8965c9a7c42\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: USB\nRegistry id: vr.tr.usb\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entry: (none)\n\nA Vercy model say" } } }, "metaModel": { "id": "THING-Q42378", "registryId": "vr.tr.usb", "name": "USB", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q42378/", "model": { "registry_id": "vr.tr.usb", "name": "USB", "purpose": "Enable an AI agent to recognise a physical USB connection or interface, assess its compatibility and condition, and decide whether and how it may safely connect devices, transfer data or deliver power.", "definition": "USB is a host-enumerated, packet-based serial interconnect family that specifies connectors and cables, differential physical-layer signalling, a hub-and-device tree, class protocols, and optional power contracts so a computing host - or a dual-role Type-C partner - can discover, configure, transfer data with, and supply power to attached devices under one electrical and software model.", "scope_statement": "Provisionally, this model owns USB as physically implemented by ports, plugs, cables and connection paths, including their supported capabilities and observed connection state; the registry must still confirm whether USB instead denotes a USB flash drive.", "in_scope": [ "USB port and plug identity, connector form and mating compatibility", "Cable and adapter capabilities across a complete USB connection path", "USB data capability, endpoint roles and observed link operation", "USB power roles, supported supply arrangements and negotiated delivery", "Connection condition, faults and permissions for USB use" ], "out_of_scope": [ "Files, storage health and capacity of a USB flash drive", "Internal operation of a connected keyboard, camera, printer or other peripheral", "Host operating-system administration and general driver lifecycle", "Charger internals, mains wiring and battery chemistry", "The full USB standards family as a normative specification", "Non-USB protocols carried through a shared connector, beyond identifying their presence and requirements" ], "distinguishing_features": [ "Establish whether USB is implemented using device documentation or observed USB behaviour; a familiar connector shape alone does not establish data or power capabilities.", "Distinguish connector form from supported USB data operation, recording separate evidence for each.", "Distinguish a USB flash drive from the USB interface it uses by identifying whether storage is the object's primary function.", "Distinguish a complete USB data path from a power-only path by checking the endpoints and every intervening cable or adapter.", "For a connector shared with other technologies, identify whether the active connection is USB or another supported operating mode." ], "characteristics": [ { "name": "Modelled physical extent", "kind": "category", "unit_or_values": "port | plug | cable assembly | adapter | complete connection path | unresolved", "why_it_matters": "Determines which capabilities and conditions belong to this instance and which belong to connected objects." }, { "name": "Connector identity", "kind": "category", "unit_or_values": "documented connector family and variant, plug or receptacle, or unknown", "why_it_matters": "Supports physical mating decisions without treating connector appearance as proof of functionality." }, { "name": "Connection topology", "kind": "relation", "unit_or_values": "linked host, peripheral, hub, power source, cable and adapter instances", "why_it_matters": "Makes intermediate components and shared resources visible when evaluating the complete path." }, { "name": "USB data capability", "kind": "category", "unit_or_values": "documented USB revision and supported signalling modes | explicitly no data capability | unknown", "why_it_matters": "Separates advertised or documented support from actual operation and prevents assumptions based on connector form." }, { "name": "Observed data operation", "kind": "state", "unit_or_values": "disconnected | attached but not enumerated | enumerated | transferring | faulted | unobserved; include active mode when known", "why_it_matters": "Distinguishes physical attachment from a usable USB data connection." }, { "name": "Data role", "kind": "category", "unit_or_values": "host | device | role-capable but inactive | unknown; record supported and current roles separately", "why_it_matters": "Helps determine whether the endpoints can establish the intended data relationship." }, { "name": "Power role and capability", "kind": "category", "unit_or_values": "source | sink | dual-role | unknown; documented supply capabilities and negotiation support", "why_it_matters": "Establishes the possible direction and conditions of power delivery independently of data roles." }, { "name": "Power operating point", "kind": "measurement", "unit_or_values": "V, A and W, with declared limits, negotiated values and measured values distinguished", "why_it_matters": "Allows an agent to compare intended demand with the constraints of the entire connection." }, { "name": "Physical connection condition", "kind": "state", "unit_or_values": "observations of contact contamination, connector deformation, cable damage, retention, moisture and heating", "why_it_matters": "Identifies evidence that connection, continued use or further testing may be inappropriate." }, { "name": "Permitted USB use", "kind": "relation", "unit_or_values": "applicable authority or policy for charging, data access, device classes and role changes", "why_it_matters": "Separates technical possibility from permission to connect or expose data." } ], "affordances": [ "Identify and label a USB port, cable or adapter with its evidenced connector and capabilities.", "Select a compatible connection path for a specified data-transfer or power-delivery task.", "Connect or disconnect endpoints when physical condition, operating state and permissions allow.", "Inspect enumeration, active data mode and power negotiation to verify the intended operation.", "Isolate a failed or limiting cable, adapter, port or endpoint through controlled substitution and testing.", "Restrict USB use to authorised functions or withdraw a damaged or untrusted component from use." ] }, "sources": [ { "id": "usb-if-usb20", "title": "Universal Serial Bus Specification, Revision 2.0", "url": "https://www.usb.org/documents", "what_it_supports": "Core host/device/hub model, descriptors, enumeration, Low/Full/High Speed rates, default 5 V VBUS and unit-load current rules.", "url_status": "live" }, { "id": "usb-if-usb4-typec-pd", "title": "USB4 Specification; USB Type-C Cable and Connector Specification; USB Power Delivery Specification", "url": "https://www.usb.org/documents", "what_it_supports": "SuperSpeed/USB4 generations, Type-C pinout and Alternate Modes, CC-based role detection, PD voltage/current contracts and electronically marked cables.", "url_status": "live" }, { "id": "iec-62680", "title": "IEC 62680 series - Universal serial bus interfaces for data and power", "url": "", "what_it_supports": "International adoption of USB-IF specifications (USB 2.0, Type-C, Power Delivery, USB 3.x) as IEC standards used in regulation and procurement." }, { "id": "eu-2022-2380", "title": "Directive (EU) 2022/2380 amending Directive 2014/53/EU (common charger)", "url": "https://eur-lex.europa.eu/eli/dir/2022/2380/oj", "what_it_supports": "EU legal requirement that specified radio equipment use USB Type-C for wired charging, which drives regional connector practice.", "url_status": "live" }, { "id": "wikidata-usb", "title": "USB (Q16340)", "url": "https://www.wikidata.org/wiki/Q16340", "what_it_supports": "Stable catalogue identifier for the USB concept as a Wikidata item.", "url_status": "live" } ], "structure": { "bundles": [ { "id": "usb-identity-and-physical-path", "name": "USB identity and physical path", "description": "Establishes what physical USB instance is being represented and how its connectors form a connection.", "rationale": "USB can name an interface, a connector-bearing object or a storage device; agents need an explicit referent and path before judging compatibility.", "layers": [ { "id": "referent-and-connector", "name": "Referent and connector", "description": "Separates the USB interface from its containing object and identifies its physical mating points.", "findings": [ { "id": "usb-instance-boundary", "name": "USB instance boundary", "description": "Records the represented physical extent and the evidence identifying its connectors as USB-related.", "questions": [ { "text": "Does this instance represent a port, plug, cable, adapter or complete connection, and which containing objects are represented elsewhere?", "kind": "boundary", "id": "usb-instance-boundary-q01" }, { "text": "What connector family, variant and plug or receptacle form is present at each mating point, and what evidence supports the identification?", "kind": "definition", "id": "usb-instance-boundary-q02" } ] } ] }, { "id": "connection-path", "name": "Connection path", "description": "Makes each endpoint and intermediate component available for compatibility assessment.", "findings": [ { "id": "path-components-and-mating", "name": "Path components and mating", "description": "Records the proposed or actual route through USB cables, adapters and hubs.", "questions": [ { "text": "Which endpoints, cables, adapters and hubs lie along the intended USB path, in connection order?", "kind": "boundary", "id": "path-components-and-mating-q01" }, { "text": "Do the mating connectors fit as intended without force, and does each intervening component have evidence of supporting the intended use?", "kind": "action", "id": "path-components-and-mating-q02" } ] } ] } ] }, { "id": "usb-data-capability-and-operation", "name": "USB data capability and operation", "description": "Separates supported USB data functions from the roles and link behaviour observed during use.", "rationale": "Physical attachment does not establish a working data path or show which endpoint can perform the required role.", "layers": [ { "id": "supported-data-functions", "name": "Supported data functions", "description": "Captures documented data support and endpoint role constraints across the path.", "findings": [ { "id": "data-support-and-roles", "name": "Data support and roles", "description": "Records evidence for USB signalling capabilities and supported data roles without deriving them from connector shape.", "questions": [ { "text": "Which USB revisions and signalling modes are supported by each endpoint and intervening component, and where is that support documented?", "kind": "provenance", "id": "data-support-and-roles-q01" }, { "text": "Which endpoint can act as host and which as device for this task, and is any part of the path explicitly limited to power delivery?", "kind": "boundary", "id": "data-support-and-roles-q02" } ] } ] }, { "id": "enumeration-and-active-link", "name": "Enumeration and active link", "description": "Records whether a usable USB data relationship has actually formed.", "findings": [ { "id": "observed-usb-session", "name": "Observed USB session", "description": "Captures enumeration, exposed functions, active mode and transfer observations for a particular connection session.", "questions": [ { "text": "What device identity and USB functions does the host report after attachment, and which expected functions are absent?", "kind": "measurement", "id": "observed-usb-session-q01" }, { "text": "What active USB mode, transfer performance and errors are observed, under which test conditions?", "kind": "measurement", "id": "observed-usb-session-q02" }, { "text": "What evidence supports retrying, changing a path component or investigating an endpoint when enumeration or transfer fails?", "kind": "action", "id": "observed-usb-session-q03" } ] } ] } ] }, { "id": "usb-power-and-shared-connector-modes", "name": "USB power and shared connector modes", "description": "Captures power arrangements and identifies other operating modes that may use the same connector.", "rationale": "Data support, power delivery and other connector-carried functions require separate evidence and can impose different path requirements.", "layers": [ { "id": "power-capability-and-contract", "name": "Power capability and contract", "description": "Distinguishes supported power arrangements from the current negotiated or measured operating point.", "findings": [ { "id": "power-path-agreement", "name": "Power path agreement", "description": "Records source and sink roles, applicable cable constraints and evidence for the current delivery arrangement.", "questions": [ { "text": "Which component supplies power, which receives it, and what voltage, current and power limits are documented for the endpoints and cable?", "kind": "provenance", "id": "power-path-agreement-q01" }, { "text": "What supply arrangement or negotiated power contract is active, and how do measured voltage and current compare with it?", "kind": "measurement", "id": "power-path-agreement-q02" }, { "text": "Can the intended load operate within the evidenced limits of this complete path, or must the agent select another source or cable?", "kind": "action", "id": "power-path-agreement-q03" } ] } ] }, { "id": "shared-connector-functions", "name": "Shared connector functions", "description": "Identifies requested functions whose support cannot be inferred from the physical connector.", "findings": [ { "id": "usb-and-other-mode-boundary", "name": "USB and other mode boundary", "description": "Records whether a requested connector-carried function uses USB or requires a separately modelled protocol or mode.", "questions": [ { "text": "Does the requested function use USB data, USB power delivery or another protocol carried through this connector?", "kind": "boundary", "id": "usb-and-other-mode-boundary-q01" }, { "text": "What evidence shows that both endpoints and every cable or adapter support the required mode and its intended concurrent functions?", "kind": "provenance", "id": "usb-and-other-mode-boundary-q02" } ] } ] } ] }, { "id": "usb-condition-and-authorised-use", "name": "USB condition and authorised use", "description": "Connects USB-specific physical and session observations to permitted next actions.", "rationale": "A technically compatible connection can still be damaged, unstable or unauthorised for the functions it exposes.", "layers": [ { "id": "connector-and-cable-condition", "name": "Connector and cable condition", "description": "Captures physical defects and intermittent behaviour along the USB path.", "findings": [ { "id": "usb-path-serviceability", "name": "USB path serviceability", "description": "Records observable connector and cable condition alongside symptoms that may indicate a faulty connection.", "questions": [ { "text": "What contact contamination, deformation, looseness, cable damage, moisture or abnormal heating is observed, and at which component?", "kind": "measurement", "id": "usb-path-serviceability-q01" }, { "text": "Do disconnects or errors follow a particular port, cable or adapter during controlled tests with known-working components?", "kind": "measurement", "id": "usb-path-serviceability-q02" }, { "text": "Which observations justify stopping use, replacing a component or following the manufacturer's inspection procedure?", "kind": "action", "id": "usb-path-serviceability-q03" } ] } ] }, { "id": "device-trust-and-session-actions", "name": "Device trust and session actions", "description": "Relates exposed USB functions and ongoing activity to connection permissions and disconnection decisions.", "findings": [ { "id": "permitted-usb-session", "name": "Permitted USB session", "description": "Records which USB functions are authorised and what must be checked before enabling or ending their use.", "questions": [ { "text": "Who authorises this connection, and are its reported storage, input, network or other USB functions permitted for the intended task?", "kind": "action", "id": "permitted-usb-session-q01" }, { "text": "If only charging is authorised, what evidence establishes that the selected connection prevents data access?", "kind": "provenance", "id": "permitted-usb-session-q02" }, { "text": "Before disconnection or a role change, what active transfers, mounted storage or power-dependent operations require coordination with the connected device's model?", "kind": "action", "id": "permitted-usb-session-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-kinds", "name": "Kinds and varieties", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "USB 1.x Low Speed and Full Speed (1.5 and 12 Mbit/s)", "USB 2.0 High Speed (480 Mbit/s), including Micro-USB and legacy Type-A/B", "USB 3.2 SuperSpeed generations (5, 10 and 20 Gbit/s; retail names USB 3.0 / 3.1 / 3.2)", "USB4 and USB4 Version 2.0 (20/40 Gbit/s, then 80 Gbit/s with optional 120 Gbit/s asymmetric)", "USB Type-C connector family, including DisplayPort and other Alternate Modes", "USB Power Delivery, including Programmable Power Supply and Extended Power Range", "USB On-The-Go and Dual-Role Device (host/device role swap)", "USB Battery Charging ports (SDP, CDP, DCP under BC 1.2)" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "scheme": "Wikidata", "value_or_pattern": "Q16340", "note": "Item for Universal Serial Bus as a technology." }, { "scheme": "USB-IF Vendor ID (idVendor)", "value_or_pattern": "16-bit, USB-IF assigned (written 0xVVVV)", "note": "Appears in the device descriptor; 0x0000 and 0xFFFF are reserved/invalid for products." }, { "scheme": "USB Product ID (idProduct)", "value_or_pattern": "16-bit, vendor-assigned (0xPPPP), unique per VID", "note": "Paired with idVendor to identify a product; not globally unique alone." }, { "scheme": "USB class codes (bDeviceClass / bInterfaceClass)", "value_or_pattern": "8-bit codes, e.g. 0x03 HID, 0x08 Mass Storage, 0x09 Hub, 0x0A CDC-data, 0x0E Video, 0xE0 Wireless, 0xFF Vendor-specific", "note": "Defined by USB-IF; 0x00 means classes live at the interface." }, { "scheme": "bcdUSB (device descriptor)", "value_or_pattern": "BCD of the USB spec the device complies with, e.g. 0x0200, 0x0300, 0x0310, 0x0320", "note": "Not a public product code; used in enumeration to select the stack." }, { "scheme": "IEC 62680", "value_or_pattern": "IEC 62680-1-1 (USB 2.0), 62680-1-2 (PD), 62680-1-3 (Type-C), 62680-2-* (USB 3.x)", "note": "Document numbers of the IEC transposition of USB-IF specs." }, { "scheme": "USB-IF Test ID (TID)", "value_or_pattern": "Integer TID issued after USB-IF compliance testing", "note": "Used on certified product listings and logo licence, not on the wire." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "USB 2.0 Specification - USB Implementers Forum (USB-IF)", "Universal Serial Bus 3.2 Specification - USB-IF", "USB4 Specification and USB4 Version 2.0 - USB-IF", "USB Type-C Cable and Connector Specification - USB-IF", "USB Power Delivery Specification - USB-IF", "Battery Charging Specification, Revision 1.2 - USB-IF", "IEC 62680 series (Universal serial bus interfaces for data and power) - International Electrotechnical Commission", "Directive (EU) 2022/2380 amending the Radio Equipment Directive 2014/53/EU (common charger / USB Type-C) - European Parliament and Council", "CISPR 32 / FCC 47 CFR Part 15 (EMC for multimedia and digital devices that include USB ports) - IEC/CISPR and U.S. FCC" ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Connecting keyboards, mice, printers, external disks, cameras and audio interfaces to PCs and embedded hosts.", "Charging and file-sync of phones and tablets over Micro-USB or USB-C, including dedicated wall chargers that speak BC 1.2 or USB PD.", "Laptop docking: one USB-C cable carrying USB data, DisplayPort Alternate Mode or USB4/Thunderbolt video, and PD sink power.", "Embedded Linux and microcontroller USB gadget/device mode (ADB, CDC-ACM serial, RNDIS/ECM networking, mass-storage).", "Retail POS scanners, payment terminals and industrial programmers that enumerate as HID or vendor-class devices.", "Automotive head units exposing USB ports for media playback and phone projection." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "quantity": "Signalling rate", "typical_range": "1.5 (Low Speed) to 80000 (USB4 v2); 120000 asymmetric optional", "unit": "Mbit/s" }, { "quantity": "VBUS voltage", "typical_range": "5 (default USB) to 48 (PD Extended Power Range); legacy fixed 5 ±5%", "unit": "V" }, { "quantity": "Available current", "typical_range": "0.1-0.5 (USB 2 unit loads), 0.9 (USB 3 default), 1.5 or 3 (Type-C CC), up to 5 (PD with e-marked cable)", "unit": "A" }, { "quantity": "PD power contract", "typical_range": "0.5-15 (legacy 5 V), 15-100 (standard PD), up to 240 (EPR)", "unit": "W" }, { "quantity": "Passive cable length in common practice", "typical_range": "USB 2.0 up to about 5; SuperSpeed/USB4 typically 0.5-3 without a repeater or active cable", "unit": "m" }, { "quantity": "Connector mating durability (specified)", "typical_range": "about 1500 (Type-A/B) to 10000 (Type-C)", "unit": "cycles" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Underspecified or counterfeit cables overheating; 5 A claims without an e-marker chip.", "Mechanical wear and broken solder joints, especially Micro-USB B and poorly supported Type-A ports.", "SuperSpeed or USB4 link-training failure with silent fallback to USB 2.0 High Speed.", "Type-C Configuration Channel faults: wrong orientation/role, no VCONN, or failed PD contract leaving the sink at 5 V or unpowered.", "Overvoltage injection from malicious adapters (so-called USB killers) destroying host controllers.", "Malicious firmware presenting as HID or a hub (BadUSB) to inject keystrokes or intercept traffic.", "Ground loops and hot-plug inrush damaging ports when chassis potentials differ.", "Enumeration failure from bogus descriptors, missing pull-ups, or hub depth/current-budget violations." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "European Union: USB Type-C is the mandated wired-charging connector for specified radio equipment (phones and similar from late 2024; laptops from 2026) under Directive (EU) 2022/2380.", "China: CCC/GB charger rules plus vendor fast-charge protocols (e.g. VOOC, SuperCharge, UFCS) that ride on USB-C but are not plain USB PD.", "Retail naming of USB 3.x is inconsistent worldwide (USB 3.0 vs 3.1 Gen 1 vs 3.2 Gen 1×1 for the same 5 Gbit/s link).", "Japan and several other markets historically used proprietary phone connectors before Micro-USB then USB-C; chargers still carry national safety marks (e.g. PSE).", "Grey-market regions sell unlicensed 'USB' cables that omit USB-IF logo certification and often fail SuperSpeed or PD tests." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ { "name": "Thunderbolt 3/4", "difference": "Same USB-C plug; Thunderbolt additionally tunnels PCIe and requires a Thunderbolt controller and certification. USB4 is the USB-IF protocol and may optionally carry Thunderbolt-compatible tunnelling; a port labelled only USB4/USB-C is not thereby a Thunderbolt port." }, { "name": "Apple Lightning", "difference": "Proprietary 8-pin connector under MFi. A Lightning accessory is not a USB connector; the device behind it may still speak USB protocol once enumerated." }, { "name": "IEEE 1394 (FireWire)", "difference": "Peer-to-peer serial bus of the same era with a different PHY, connector family and addressing; it does not use USB enumeration or USB class codes." }, { "name": "Native DisplayPort", "difference": "A dedicated DP receptacle carries DisplayPort only. DisplayPort Alternate Mode re-uses USB Type-C SuperSpeed pairs; presence of a USB-C port does not imply DP Alt Mode unless the port advertises it." }, { "name": "UART / RS-232", "difference": "Asynchronous character serial with no enumeration. USB CDC-ACM is a USB device class that carries a UART-like stream after USB configuration; a USB-serial adapter is USB on the host side, UART on the other." }, { "name": "eSATA / Powered-B", "difference": "eSATA is Serial ATA with a similar-era external plug. USB 3.0 Powered-B and some combo receptacles look related; SATA framing and USB packets are not interchangeable - check the receptacle keying and whether the host enumerates a USB device or an ATA disk." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of USB this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does vr.tr.usb denote the USB interface and its physical implementations, a USB flash drive, or another intended registry concept?", "Does an existing Vercy world model already own this concept, requiring a registry link instead of a separate publication?", "Which USB connector families, specification revisions and legacy power arrangements must the researched model cover?", "Where should ownership divide between this entry and models for cables, connectors, hubs, chargers and non-USB modes using the same connector?", "Which authoritative documentation and permitted observations can substantiate cable capability, power limits and stop-use criteria when markings or device reports are incomplete?" ], "statistics": { "bundles": 5, "layers": 9, "findings": 16, "questions": 28 } }, "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 USB, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise a physical USB connection or interface, assess its compatibility and condition, and decide whether and how it may safely connect devices, transfer data or deliver power.", "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: HID++, USB On-The-Go, USB standard connector adapter, USB condom, USB 2 connector adapter.", "5 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 92 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 USB, 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 USB 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": [ "HID++", "USB On-The-Go", "USB standard connector adapter", "USB condom", "USB 2 connector adapter" ] } ], "standing": "Described in 92 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 5 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 USB from another, and a USB 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 USB, 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 USB, 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 USB 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 USB, 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 USB, 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 USB 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 USB 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 USB, 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 USB, 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 USB 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 USB from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a USB, 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 USB, 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 USB 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 USB 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 USB, 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 USB, 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 USB 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 USB is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a USB, 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 USB, 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 USB 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 USB is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a USB, 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 USB, 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 USB 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 USB 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 USB is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a USB, 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 USB, 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 USB 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 USB 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 USB, 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 USB, 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 USB 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 USB 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 USB between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a USB, 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 USB, 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 USB 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 USB, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a USB 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 USB, 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 USB, 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 USB 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 USB 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 USB is for, and what it is used for anyway.", "findings": [ { "id": "function-and-purpose", "name": "Function, purpose and misuse", "description": "The function a USB performs and the uses that fall outside it.", "questions": [ { "id": "function-and-purpose-q01", "text": "What identifies and describes the use of a USB, 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 USB, 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 USB 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 USB.", "findings": [ { "id": "procedures-and-skills", "name": "Procedures, skills and required tools", "description": "What an agent needs before it can act on a USB at all.", "questions": [ { "id": "procedures-and-skills-q01", "text": "What identifies and describes handling a USB, 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 USB, 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 USB 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 USB 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 USB and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a USB, 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 USB, 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 USB 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 USB is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a USB, 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 USB, 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 USB 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 } } } }