{ "model": { "rank": 6264, "code": "thing-q1033951", "model_id": "vr.tr.device-driver", "name": "device driver", "purpose": "Enable an AI agent to recognise a device driver, assess whether it can safely mediate access to a particular device in a particular execution environment, and determine permitted lifecycle and operational actions.", "family": "Thing Registry", "category": "Physical world and living systems", "status": "research-draft", "kind": "thing", "plane": "PHY", "domain": "PHY.OBJ", "industry": "", "version": "", "url": "/models/thing/q1033951/", "tier": 2, "score": 61, "payload": { "layer": "wikidata", "aliases": [ "proprietary device driver", "Vinum", "Virtual audio driver", "JDBC driver", "VMM", "VxD", "JDBC Type 1 Driver", "JDBC Type 2 Driver", "JDBC Type 3 driver", "JDBC Type 4 Driver" ], "aliasCount": 10, "merged": 10, "knownIn": 61, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q1033951", "url": "https://www.wikidata.org/wiki/Q1033951", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T13:30:28Z", "providers": [ "Codex", "Grok" ], "missingProviders": [], "pass": 2, "cost": { "grok": { "usd": 0.00526456, "turns": 1, "seconds": 92.5, "error": null }, "codex": { "seconds": 76.2, "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: 01a07c0e-c094-7d42-afe7-817adc4acda8\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: device driver\nRegistry id: vr.tr.device-driver\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entry: (none" } } }, "metaModel": { "id": "THING-Q1033951", "registryId": "vr.tr.device-driver", "name": "device driver", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q1033951/", "model": { "registry_id": "vr.tr.device-driver", "name": "device driver", "purpose": "Enable an AI agent to recognise a device driver, assess whether it can safely mediate access to a particular device in a particular execution environment, and determine permitted lifecycle and operational actions.", "definition": "A kernel-mode or privileged software component that implements a device-class or bus protocol so the operating system and user-space programs can access a specific hardware device (or a virtual stand-in) through a stable, OS-defined interface rather than by programming the device registers themselves.", "scope_statement": "This model owns the identity, device-facing responsibilities, compatibility conditions, deployment state, operational evidence and authority boundaries of a software device driver, while leaving the registry's PHY / PHY.OBJ classification unresolved.", "in_scope": [ "Driver implementation, release and installed-instance identity", "Supported device identities, revisions and binding rules", "Host interfaces, dependencies and execution requirements", "Installation, loading, binding, updating and removal conditions", "Device-control behaviour, operational health and recovery evidence", "Driver provenance, privileges and restrictions on agent actions" ], "out_of_scope": [ "Physical device construction, ownership and hardware maintenance", "Device firmware implementation and its independent update lifecycle", "Operating-system internals beyond the driver's dependencies and interfaces", "Application workflows that consume device services", "Generic package distribution infrastructure", "Human-operated tools or circuits called drivers unless registry research establishes that meaning" ], "distinguishing_features": [ "Identify the host interface through which the component exposes device operations; merely calling an existing device interface does not establish that an application is a driver.", "Identify the device endpoint or device class whose access the component mediates; distinguish the mediating software from the hardware it controls.", "Establish the component's execution and deployment boundary to distinguish host driver code from firmware executed within the device.", "Inspect package contents and active components to distinguish the driver implementation from its installer, configuration utility and supporting services.", "Determine whether the component serves a physical device, a virtual device or a device-stack filtering role before assigning its operational boundaries." ], "characteristics": [ { "name": "Driver identity and release", "kind": "category", "unit_or_values": "Implementation name, provider, version, build identifier and artifact digest where available", "why_it_matters": "Separates similarly named drivers and identifies exactly which implementation the evidence concerns." }, { "name": "Supported device match", "kind": "relation", "unit_or_values": "Device identifiers, classes, revisions and exclusions linked to supporting evidence", "why_it_matters": "Prevents a broad product-family match from being treated as proof of compatibility." }, { "name": "Host compatibility", "kind": "relation", "unit_or_values": "Operating-system release, architecture, driver-interface requirements and dependencies", "why_it_matters": "Determines whether the driver can be installed and executed in the target environment." }, { "name": "Execution placement", "kind": "category", "unit_or_values": "Kernel, user-space, mixed or unresolved; associated process or module", "why_it_matters": "Helps assess isolation, failure impact and required authority." }, { "name": "Deployment and binding state", "kind": "state", "unit_or_values": "Separately evidenced package presence, load state, device binding, enablement and restart requirement", "why_it_matters": "An installed package does not establish that its driver is active for a device." }, { "name": "Device-stack role", "kind": "category", "unit_or_values": "Environment-specific role such as function, bus, filter, class or virtual-device provider", "why_it_matters": "Clarifies which operations and failures can reasonably be attributed to this driver." }, { "name": "Granted access", "kind": "relation", "unit_or_values": "Granted privileges and access to device resources, memory and caller interfaces", "why_it_matters": "Establishes the driver's authority and the consequences of misuse or compromise." }, { "name": "Observed operation failures", "kind": "measurement", "unit_or_values": "Failed operations / observed operations, with operation type, interval and configuration", "why_it_matters": "Provides contextual health evidence without treating every device failure as a driver defect." }, { "name": "Operation latency", "kind": "measurement", "unit_or_values": "Milliseconds, with operation, percentile, workload and measurement boundary", "why_it_matters": "Supports diagnosis of timeouts and performance changes under comparable conditions." }, { "name": "Trust and support assessment", "kind": "state", "unit_or_values": "Signature verification result, policy acceptance, support status and assessment date recorded separately", "why_it_matters": "Distinguishes artifact authenticity, local permission to load and ongoing maintenance." } ], "affordances": [ "Identify the driver actually bound to a device and compare it with the intended release.", "Check device, host and dependency compatibility before proposing deployment.", "Inspect available logs, counters and device-operation results to assess health.", "Install, update, bind, disable or remove the driver when authority and operational preconditions permit.", "Run supported diagnostics or recovery actions within an explicit disruption budget.", "Prepare and verify rollback or alternate device access before changing a critical driver." ] }, "sources": [ { "id": "src-wikipedia-device-driver", "title": "Device driver", "url": "https://en.wikipedia.org/wiki/Device_driver", "what_it_supports": "Core definition as hardware-interface software; kernel vs user-mode placement; virtual devices; class/bus/function distinctions used in practice.", "url_status": "live" }, { "id": "src-microsoft-wdk-getting-started", "title": "Getting started with drivers - Windows Driver Kit (WDK)", "url": "https://learn.microsoft.com/en-us/windows-hardware/drivers/gettingstarted/", "what_it_supports": "Windows KMDF/UMDF/WDM kinds, driver stacks, INF packaging, WHQL/attestation signing as the practical identity of a Windows driver.", "url_status": "live" }, { "id": "src-kernel-driver-model", "title": "Linux Device Drivers, 3rd Edition - Chapter 1: An Introduction to Device Drivers (online)", "url": "https://www.oreilly.com/library/view/linux-device-drivers/0596005903/ch01.html", "what_it_supports": "POSIX/Linux character, block and network device classes; module vs in-tree; the driver as the kernel's hardware abstraction, not the userspace library.", "url_status": "blocked" }, { "id": "src-pci-sig-spec", "title": "PCI Express Base Specification (overview of software/device interface)", "url": "https://pcisig.com/specifications", "what_it_supports": "Bus-level identifiers (Vendor ID / Device ID / Class Code) that operating systems use to bind a driver to a function; neighbour relationship to firmware and BARs.", "url_status": "live" } ], "structure": { "bundles": [ { "id": "driver-identity-and-role", "name": "Driver identity and role", "description": "Establish what component is being modelled and where it participates in device access.", "rationale": "Driver packages, loaded implementations and device-bound instances can have different identities and responsibilities.", "layers": [ { "id": "implementation-and-instance", "name": "Implementation and instance", "description": "Connect the named driver to concrete artifacts and runtime instances.", "findings": [ { "id": "artifact-to-runtime-identity", "name": "Artifact-to-runtime identity", "description": "Record the evidence connecting a provider release, installed files and the active driver instance.", "questions": [ { "text": "Does this record describe a driver family, a specific release or an instance running on a particular host?", "kind": "definition", "id": "artifact-to-runtime-identity-q01" }, { "text": "Which package metadata, artifact identifiers and runtime observations establish that identity?", "kind": "provenance", "id": "artifact-to-runtime-identity-q02" } ] } ] }, { "id": "device-stack-position", "name": "Device-stack position", "description": "Locate the driver's responsibility between callers, other drivers and device endpoints.", "findings": [ { "id": "mediation-responsibility", "name": "Mediation responsibility", "description": "Identify the device operations this component implements, translates, forwards or filters.", "questions": [ { "text": "Which device endpoint and caller-facing interface does this driver connect?", "kind": "definition", "id": "mediation-responsibility-q01" }, { "text": "Which responsibilities belong to adjacent drivers, firmware or supporting services?", "kind": "boundary", "id": "mediation-responsibility-q02" } ] } ] } ] }, { "id": "compatibility-and-binding", "name": "Compatibility and binding", "description": "Describe the conditions under which the driver can serve a target device.", "rationale": "Device recognition, host compatibility and actual driver selection are separate conditions for usable access.", "layers": [ { "id": "device-eligibility", "name": "Device eligibility", "description": "Determine which devices and revisions are eligible for this implementation.", "findings": [ { "id": "supported-device-evidence", "name": "Supported device evidence", "description": "Record declared matches, exclusions and observed compatibility without conflating them.", "questions": [ { "text": "Which device identifiers, interface classes and hardware or firmware revisions are declared supported?", "kind": "boundary", "id": "supported-device-evidence-q01" }, { "text": "Which provider documentation, matching metadata or tests support compatibility with this exact device?", "kind": "provenance", "id": "supported-device-evidence-q02" } ] } ] }, { "id": "host-and-selection-conditions", "name": "Host and selection conditions", "description": "Capture host requirements and the mechanism selecting a driver for a device.", "findings": [ { "id": "loadability-and-binding", "name": "Loadability and binding", "description": "Establish whether the host can load the implementation and whether it is selected for the intended endpoint.", "questions": [ { "text": "Which host release, architecture, driver interface and dependencies must be satisfied?", "kind": "boundary", "id": "loadability-and-binding-q01" }, { "text": "What evidence shows the current binding, and what selection rule or competing driver could change it?", "kind": "measurement", "id": "loadability-and-binding-q02" } ] } ] } ] }, { "id": "deployment-and-recovery", "name": "Deployment and recovery", "description": "Represent driver lifecycle transitions and their operational consequences.", "rationale": "Changing a driver can interrupt access to the very storage, network or input device needed to recover the host.", "layers": [ { "id": "lifecycle-transitions", "name": "Lifecycle transitions", "description": "Separate package installation from loading, binding and effective activation.", "findings": [ { "id": "effective-activation-state", "name": "Effective activation state", "description": "Record the current lifecycle state and prerequisites for a requested transition.", "questions": [ { "text": "Is the intended release present, loaded, bound and enabled, and is any transition pending a restart?", "kind": "measurement", "id": "effective-activation-state-q01" }, { "text": "Which supported procedure and prerequisites apply to installation, replacement, unbinding or removal?", "kind": "action", "id": "effective-activation-state-q02" } ] } ] }, { "id": "continuity-and-rollback", "name": "Continuity and rollback", "description": "Protect dependent operations and preserve a workable recovery route.", "findings": [ { "id": "recoverable-driver-change", "name": "Recoverable driver change", "description": "Identify disruption risks and evidence that the previous working configuration can be restored.", "questions": [ { "text": "Which active workloads and recovery channels depend on the device whose driver will change?", "kind": "boundary", "id": "recoverable-driver-change-q01" }, { "text": "What retained driver, configuration and alternate access path enable rollback, and how will restored operation be verified?", "kind": "action", "id": "recoverable-driver-change-q02" } ] } ] } ] }, { "id": "device-operations-and-health", "name": "Device operations and health", "description": "Connect supported device behaviour with observations of correct or degraded operation.", "rationale": "A loaded driver can still fail particular commands, workloads or device-state transitions.", "layers": [ { "id": "operation-contract", "name": "Operation contract", "description": "Describe the operations exposed through this driver and their applicable conditions.", "findings": [ { "id": "supported-commands-and-transitions", "name": "Supported commands and transitions", "description": "Record available operations, completion behaviour and relevant device-state constraints.", "questions": [ { "text": "Which operations does this driver expose, and how are successful completion, failure and cancellation reported?", "kind": "definition", "id": "supported-commands-and-transitions-q01" }, { "text": "What restrictions apply during device removal, power transitions, reset or concurrent access?", "kind": "boundary", "id": "supported-commands-and-transitions-q02" } ] } ] }, { "id": "health-and-fault-attribution", "name": "Health and fault attribution", "description": "Assess observed operation and separate driver evidence from neighbouring failure causes.", "findings": [ { "id": "diagnostic-evidence", "name": "Diagnostic evidence", "description": "Associate errors and performance observations with a specific driver, device and workload configuration.", "questions": [ { "text": "Which logs, error counts, timeout observations or latency measurements describe this driver's operation under a stated workload?", "kind": "measurement", "id": "diagnostic-evidence-q01" }, { "text": "What evidence distinguishes a driver defect from hardware, firmware, transport or caller failure?", "kind": "boundary", "id": "diagnostic-evidence-q02" }, { "text": "Which supported diagnostic or reset action can narrow the cause within the permitted service interruption?", "kind": "action", "id": "diagnostic-evidence-q03" } ] } ] } ] }, { "id": "trust-and-control-authority", "name": "Trust and control authority", "description": "Determine whether the driver is acceptable to execute and which changes an agent may perform.", "rationale": "Drivers mediate device resources, so artifact trust and authority to alter device access require explicit evidence.", "layers": [ { "id": "artifact-trust", "name": "Artifact trust", "description": "Assess origin, integrity, policy acceptance and maintenance evidence for the specific release.", "findings": [ { "id": "release-trust-evidence", "name": "Release trust evidence", "description": "Record independently evidenced authenticity, load-policy acceptance and known release restrictions.", "questions": [ { "text": "Where was this artifact obtained, and what integrity or signature verification was actually performed?", "kind": "provenance", "id": "release-trust-evidence-q01" }, { "text": "Which current support notices, security advisories or local load policies constrain use of this release?", "kind": "boundary", "id": "release-trust-evidence-q02" } ] } ] }, { "id": "privileges-and-agent-actions", "name": "Privileges and agent actions", "description": "Connect execution privileges and resource exposure to permitted interventions.", "findings": [ { "id": "device-control-authorisation", "name": "Device-control authorisation", "description": "Record the driver's resource access and the agent's separate authority to inspect or change it.", "questions": [ { "text": "Where does the driver execute, which device or memory resources can it access, and which callers can invoke its control interface?", "kind": "boundary", "id": "device-control-authorisation-q01" }, { "text": "Which driver changes and device-control operations is this agent authorised to perform, under what conditions?", "kind": "action", "id": "device-control-authorisation-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-kinds", "name": "Kinds and varieties", "description": "Reported by the breadth pass; each item needs checking against its source before it becomes normative.", "evidence": [ "Kernel-mode / ring-0 driver (Windows KMDF/WDM, Linux in-tree module, BSD kmod)", "User-mode driver (Windows UMDF, Linux FUSE/UIO/VFIO userspace, some printer and scanner stacks)", "Bus / host-controller driver (PCI, USB, I2C, SPI, Thunderbolt)", "Class / function driver (storage, network, display, audio, HID, serial)", "Filter / miniport / stacked driver (upper/lower filters, NDIS miniport, SCSI miniport)", "Virtual / paravirtual / hypervisor driver (virtio, Hyper-V VSC/VSP, vGPU)", "Firmware-assisted / offloaded driver (SmartNIC, DPDK PMD, GPU kernel-mode plus user-mode ICD)", "Boot / early-init driver (UEFI driver, initramfs storage/network, Windows boot-start)" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of device driver 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": "Q750548", "note": "item 'device driver' (software that operates or controls a particular type of device)" }, { "scheme": "PCI ID", "value_or_pattern": "VVVV:DDDD[.SSSS] (4-digit hex Vendor ID : Device ID, optional Subsystem)", "note": "pci.ids / PCI-SIG assigned IDs used by OS match tables (Linux modalias, Windows INF Hardware IDs)" }, { "scheme": "USB ID", "value_or_pattern": "USB\\VID_vvvv&PID_pppp[&REV_rrrr[&MI_nn]]", "note": "USB-IF vendor/product IDs; Windows hardware-ID syntax; Linux usb:vXXXXpYYYY*" }, { "scheme": "Windows Hardware ID / Compatible ID", "value_or_pattern": "PCI\\VEN_vvvv&DEV_dddd&SUBSYS_ssssrrrr&REV_nn ; USB\\... ; ACPI\\... ; HID\\...", "note": "INF matching keys that bind a .sys/.dll package to a PnP node" }, { "scheme": "Linux modalias / MODULE_DEVICE_TABLE", "value_or_pattern": "pci:v0000VVVVd0000DDDDsv*sd*bc*sc*i* ; usb:vXXXXpYYYY*", "note": "depmod/udev alias used to autoload a kernel module" }, { "scheme": "Windows driver package / catalog", "value_or_pattern": "INF file + CAT catalog + Authenticode/attestation signature; Driver Store path FileRepository\\_", "note": "the installable identity of a Windows driver, distinct from the binary .sys name" } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of device driver 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-IF USB 2.0/3.x specifications - device class documents that define which class driver (HID, MSC, CDC, UVC, UAC) an OS may bind without a vendor driver", "PCI-SIG PCI Express Base Specification - configuration space, BARs, Vendor/Device/Class IDs used for driver matching", "UEFI Forum UEFI Specification (Driver Execution Environment, EFI Driver Model) - boot-time device drivers loaded from firmware or option ROMs", "IEEE 1275-1994 (Open Firmware / IEEE Std 1275) - historical open firmware driver model (SPARC, PowerPC, some ARM)", "ISO/IEC 9945 (POSIX.1) - portable I/O and device-file semantics that user programs see; does not specify kernel driver ABI", "Microsoft Windows Hardware Compatibility Program / WHCP and kernel-mode code integrity (Attestation / EV signing, HVCI) - required to load drivers on 64-bit Windows", "Linux kernel ABI / DKMS practice and GPLv2 licensing of in-tree drivers - de facto standard for Linux driver form, not an ISO standard", "UNECE WP.29 / ISO 21434 and IEC 62443 (when the driver is in an automotive or industrial control system) - cybersecurity process applied to driver supply chain rather than the driver format itself", "EU Cyber Resilience Act (Regulation (EU) 2024/2847) and US FDA premarket guidance for device software (when the driver ships with a medical or consumer connected product) - product-level duties that include driver update and vulnerability handling" ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of device driver 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": [ "OS boot: a storage and filesystem driver (AHCI/NVMe + NTFS/ext4) must load before the root volume is mounted; network drivers load for PXE/iSCSI boot.", "Plug-and-play: inserting a USB stick or PCIe NIC causes the OS to match Vendor/Product or Class IDs and bind a class or vendor driver; Windows copies the package into the Driver Store.", "OEM system image: laptop vendors ship INF + signed binaries for GPU, Wi-Fi, audio, and HID; Linux distros ship the same hardware via in-tree modules or linux-firmware blobs plus a kernel module.", "Printers and scanners: often a user-mode driver (Windows print driver / IPP Everywhere / CUPS filter) rather than a kernel module; the kernel only exposes USB/IPP.", "Virtual machines: guest virtio-net/blk or Hyper-V synthetic drivers replace emulated hardware for I/O.", "Embedded and RTOS: a board-support package registers drivers for SoC peripherals (UART, I2C, GPIO, Ethernet MAC) against a HAL or device-tree.", "Malware and anti-cheat: kernel drivers are used both as signed anti-cheat / EDR sensors and as a persistence/privilege-escalation vehicle (vulnerable signed drivers)." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of device driver 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": "Driver binary / package size", "typical_range": "10 KiB (GPIO/UART) to 50-500 MiB (GPU packages with user-mode stacks)", "unit": "bytes" }, { "quantity": "Initialization / probe latency", "typical_range": "0.1-50 ms for simple USB/PCI functions; 0.5-10 s for GPU or Wi-Fi firmware load", "unit": "seconds" }, { "quantity": "I/O throughput of the bound device (as seen through the driver)", "typical_range": "12-480 Mbit/s (USB 2), ~1-200 Gbit/s (NIC), ~1-14 GB/s (NVMe)", "unit": "bit/s or byte/s" }, { "quantity": "Interrupt / DPC / NAPI latency", "typical_range": "1-100 µs typical; milliseconds under load or with poorly written ISRs", "unit": "seconds" }, { "quantity": "Kernel-mode CPU overhead", "typical_range": "<1 % idle polling-off; 5-30 % of one core under high packet or block I/O without offload", "unit": "percent of CPU" }, { "quantity": "CVE / vulnerability count in a vendor driver family per year", "typical_range": "0-several dozen for large GPU/Wi-Fi stacks; long-tail of BYOVD (bring-your-own-vulnerable-driver) CVEs", "unit": "count per year" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of device driver 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": [ "Bugcheck / kernel panic from a null pointer, use-after-free, or deadlock in kernel-mode code (Windows DRIVER_IRQL_NOT_LESS_OR_EQUAL, Linux oops in module).", "Device not found / Code 28 / missing module: no matching INF or modalias, unsigned driver blocked by Secure Boot or HVCI.", "Wrong driver bound (generic class driver vs vendor driver) causing missing features, reduced speed, or bricked firmware updates.", "Firmware load failure or version skew between driver and device firmware (Wi-Fi, GPU, SSD).", "Resource leak: DMA buffers, interrupt lines, or I/O memory not released on surprise removal; can stall the bus.", "Privilege-escalation hazard: a signed kernel driver with a write-what-where IOCTL is reused by malware (BYOVD).", "Performance collapse from interrupt storms, disabled offloads, or polling threads that pin CPUs.", "Supply-chain / update hazard: a compromised driver update signs and loads into every kernel that trusts the vendor certificate." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of device driver 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": [ "Windows-centric OEM markets (consumer PCs) distribute drivers as WHQL/attestation-signed INF packages; Linux-centric servers and Android/embedded use in-tree modules plus a linux-firmware blob, with no INF.", "China and some enterprise environments require domestic cryptographic modules and locally signed kernel modules; Western Windows requires Microsoft attestation or EV + WHCP.", "Japanese and some industrial OEMs still ship vendor-specific serial and GPIB drivers; EU public-sector printing has shifted toward driverless IPP Everywhere / Mopria.", "macOS/iOS use the DriverKit / I/O Kit user-space dext model and App Store notarization rather than kernel kexts (kexts largely deprecated since macOS Catalina/Big Sur).", "Naming: US/Windows 'device driver' vs Unix 'kernel module' / 'device driver' vs historical 'device handler'; printers often called 'print driver' even when entirely user-mode." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of device driver 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": "firmware (device ROM, option ROM, UEFI driver, microcontroller code)", "difference": "Firmware runs on the device or in pre-OS firmware; a device driver runs on the host CPU under the OS. Test: after the OS has booted, is the code loaded into the kernel/user driver framework and bound to a PnP node or /dev node? If it ran from SPI flash before the OS, it is firmware." }, { "name": "userspace library / SDK / HAL (OpenGL/Vulkan ICD, libusb, vendor SDK)", "difference": "A library is linked by an application and has no kernel privilege unless it talks to a driver. Test: does unloading it require a kernel module unload, DriverStore removal, or just unlinking a .so/.dll from a process?" }, { "name": "operating-system kernel / HAL", "difference": "The kernel is the host; a driver is a loadable (or compiled-in) component that the kernel binds to a device class. Test: is it optional per device and matched by hardware ID, or is it the scheduler/memory manager itself?" }, { "name": "device tree / ACPI / INF / udev rule (hardware description)", "difference": "These describe which driver to bind and with which properties; they are not the driver. Test: can the file execute I/O to the device by itself? If it only names a compatible string or Hardware ID, it is description, not a driver." }, { "name": "microcode / CPU update", "difference": "Microcode patches the processor itself and is applied by the BIOS or OS early; it is not bound to a peripheral. Test: is the payload a CPUID-matched patch from Intel/AMD, or a module matched to a PCI/USB ID?" }, { "name": "virtual device / hypervisor backend (QEMU device model, Hyper-V VSP)", "difference": "The backend emulates or multiplexes the device in the host; the guest still loads a (para)virtual driver. Test: which address space does the code run in - guest kernel (driver) or host hypervisor (backend)?" } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of device driver this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does this registry entry mean software that mediates device access, an electronic driver component, or another physical object, given its PHY / PHY.OBJ placement and missing definition?", "Does an existing Vercy world model already cover the intended concept and require this registry entry to link to it?", "Should the model cover a driver family, release and deployed instance together, or treat them as related records with distinct state evidence?", "Which operating systems and driver frameworks must the model support, and which lifecycle or device-stack terms require platform-specific interpretation?", "Are virtual-device, filter and user-space drivers included, and where should their boundaries with firmware and supporting services be drawn?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 29 } }, "draft": { "generator": "vr.draft.v3", "status": "draft-generated", "researched": false, "archetype": "device, machine or tool", "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 device driver, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise a device driver, assess whether it can safely mediate access to a particular device in a particular execution environment, and determine permitted lifecycle and operational actions.", "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: proprietary device driver, Vinum, Virtual audio driver, JDBC driver, VMM, VxD, JDBC Type 1 Driver, JDBC Type 2 Driver, JDBC Type 3 driver, JDBC Type 4 Driver.", "10 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 61 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 device driver, 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, by the arrangement of its controls, and by markings - a plate, a model number, a certification mark. Form alone rarely separates two models that do very different things." ], "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": [ "proprietary device driver", "Vinum", "Virtual audio driver", "JDBC driver", "VMM", "VxD", "JDBC Type 1 Driver", "JDBC Type 2 Driver", "JDBC Type 3 driver", "JDBC Type 4 Driver" ] } ], "standing": "Described in 61 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 10 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 device driver from another, and a device driver 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 device driver, 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 device driver, 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 device driver 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 device driver, 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 device driver, 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 device driver 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 device driver 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 device driver, 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 device driver, 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 device driver 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 device driver from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a device driver, 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 device driver, 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 device driver 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 device driver 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 device driver, 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 device driver, 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 device driver 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 device driver is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a device driver, 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 device driver, 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 device driver 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 device driver is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a device driver, 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 device driver, 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 device driver 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 device driver 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 device driver is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a device driver, 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 device driver, 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 device driver 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 device driver 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 device driver, 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 device driver, 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 device driver 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 device driver 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 device driver between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a device driver, 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 device driver, 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 device driver 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 device driver, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a device driver 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 device driver, 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 device driver, 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 device driver is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] }, { "id": "function-and-principle", "name": "Function and operating principle", "description": "What device driver is for and how it achieves it.", "rationale": "Two devices with the same name can work on different principles, and the principle is what predicts failure and constrains use.", "layers": [ { "id": "intended-function", "name": "Intended function", "description": "The job it does, and the jobs it is used for anyway.", "findings": [ { "id": "function-record", "name": "Function, principle and variants", "description": "What it does, how, and which variants do it differently.", "questions": [ { "id": "function-record-q01", "text": "What function does device driver perform, on what operating principle, and which variants differ in that principle?", "kind": "definition" }, { "id": "function-record-q02", "text": "What use falls outside the intended function but happens in practice?", "kind": "boundary" } ] } ] }, { "id": "capacity-and-rating", "name": "Capacity and rating", "description": "The numbers that say what it can do and where it stops.", "findings": [ { "id": "ratings", "name": "Ratings and their conditions", "description": "Rated capacity, power, throughput and the conditions each assumes.", "questions": [ { "id": "ratings-q01", "text": "What ratings characterise device driver, in what units, and under what stated conditions?", "kind": "measurement" }, { "id": "ratings-q02", "text": "What happens beyond the rating - degradation, refusal, damage - and how is that detected?", "kind": "action" } ] } ] } ] }, { "id": "operation-and-state", "name": "Operation, controls and state", "description": "How device driver is operated and what state it is in right now.", "rationale": "An agent acting on a device needs its current state and the controls that change it, not just its specification.", "layers": [ { "id": "controls-and-modes", "name": "Controls and modes", "description": "What can be set, what that changes, and what is interlocked.", "findings": [ { "id": "control-surface", "name": "Control surface and interlocks", "description": "The settings available and the conditions that block them.", "questions": [ { "id": "control-surface-q01", "text": "What controls and modes does device driver have, and what does each change?", "kind": "definition" }, { "id": "control-surface-q02", "text": "Which actions are interlocked or forbidden in which state, and what must be true before acting?", "kind": "action" } ] } ] }, { "id": "condition-and-maintenance", "name": "Condition and maintenance", "description": "Wear, service intervals, consumables and the line between working and broken.", "findings": [ { "id": "service-record", "name": "Condition, service and consumables", "description": "What is consumed, what is serviced, and how condition is judged.", "questions": [ { "id": "service-record-q01", "text": "What consumables and service does device driver need, at what interval, and on whose authority?", "kind": "measurement" }, { "id": "service-record-q02", "text": "What evidence separates a unit that is working from one that is out of service?", "kind": "boundary" } ] } ] } ] }, { "id": "kind-model-unit", "name": "Kind, model and unit", "description": "Whether a claim about device driver is about the kind, a product line, or one physical unit.", "rationale": "This is the boundary most often got wrong for made things, and getting it wrong mixes a catalogue entry with the machine in the yard.", "layers": [ { "id": "level-of-reference", "name": "Level of reference", "description": "The three levels and what belongs at each.", "findings": [ { "id": "level-rules", "name": "What belongs to kind, model and unit", "description": "Which properties are shared by all of them and which are not.", "questions": [ { "id": "level-rules-q01", "text": "Which facts about device driver hold for every one of them, which for a model, and which only for one unit?", "kind": "boundary" }, { "id": "level-rules-q02", "text": "What identifies an individual unit, and what should an agent do when it has only the kind?", "kind": "action" } ] } ] }, { "id": "standards-and-conformity", "name": "Standards and conformity", "description": "The standards a working example must meet and who attests it.", "findings": [ { "id": "conformity", "name": "Standards, marks and attestation", "description": "Which standard applies, who certifies, and what the mark means.", "questions": [ { "id": "conformity-q01", "text": "Which standards govern device driver, issued by whom, and what does conformity actually assert?", "kind": "provenance" }, { "id": "conformity-q02", "text": "What may an agent conclude from a certification mark, and what may it not?", "kind": "boundary" } ] } ] } ] }, { "id": "provenance-and-evidence", "name": "Provenance, evidence and time", "description": "Where every claim about a device driver 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 device driver and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a device driver, 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 device driver, 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 device driver 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 device driver is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a device driver, 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 device driver, 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 device driver is known, and what must it refuse?", "kind": "action", "answer_data": [ "permitted actions", "preconditions", "refusals", "escalation" ] } ] } ] } ] } ] }, "statistics": { "bundles": 8, "layers": 17, "findings": 19, "questions": 51 } } } }