{ "model": { "rank": 6669, "code": "thing-q165233", "model_id": "vr.tr.network-interface-controller", "name": "network interface controller", "purpose": "Enable an agent to recognise a network interface controller, assess its connectivity and operating state, and determine compatible and authorised configuration, use and maintenance 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/q165233/", "tier": 2, "score": 59, "payload": { "layer": "wikidata", "aliases": [ "converged network adapter", "data processing unit", "RTL8153", "TP-Link UE300", "wired network adapter", "wireless network adapter", "wireless network interface controller", "NE1000", "3Com 3c509", "TP-LINK TL-WN822N v1", "Killer NIC", "Kedron", "NE2000", "WIC", "Nvidia BlueField", "Rocketfish RF-FLBTAD" ], "aliasCount": 16, "merged": 16, "knownIn": 59, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q165233", "url": "https://www.wikidata.org/wiki/Q165233", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-09T23:15:13Z", "providers": [ "Codex" ], "breadth": "recalled by Codex without web access - no source was read", "missingProviders": [], "pass": 2, "cost": { "grok": { "seconds": 23, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a08873-4984-7522-9113-2a8995ac8f19\n--------\nuser\nDescribe what is already known about one registered thing. Answer as JSON only, no prose around it.\n\nThing: network interface controller\nSense to describe: (none recorded)\nDomain code: PHY.OBJ\nAlso known as: (none)\n\n\nContext for this batch of 1001 things:\n# Ba", "usd": 0, "recall": true }, "codex": { "seconds": 61.7, "error": "Reading additional input from stdin...\nOpenAI Codex v0.153.4\n--------\nworkdir: R:\\02_PROJECTS\\02_Meta_Models_Platforms\\Ver.cy\\current\\thing-registry-backlog\nmodel: gpt-6-astra\nprovider: openai\napproval: never\nsandbox: read-only\nreasoning effort: none\nreasoning summaries: none\nsession id: 01a08873-499b-7dc2-9900-cfad7889246b\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: network interface controller\nRegistry id: vr.tr.network-interface-controller\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames" } } }, "metaModel": { "id": "THING-Q165233", "registryId": "vr.tr.network-interface-controller", "name": "network interface controller", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q165233/", "model": { "registry_id": "vr.tr.network-interface-controller", "name": "network interface controller", "purpose": "Enable an agent to recognise a network interface controller, assess its connectivity and operating state, and determine compatible and authorised configuration, use and maintenance actions.", "definition": "A network interface controller is a hardware component that connects a host system to a network by implementing network-medium access and exchanging network data with the host through a hardware interface and device driver.", "scope_statement": "This model owns the physical network interface controller as a kind of host-attached or host-integrated hardware, including its network-facing interfaces, host-facing data path, capabilities and operational constraints; product specifications and individual units supply evidence for these properties.", "in_scope": [ "Controller hardware implemented as an integrated circuit, board component or network adapter", "Host attachment, device enumeration, driver and firmware dependencies", "Network ports or radio interfaces, link capabilities and address handling", "Transmit and receive queues, packet transfer and supported hardware offloads", "Link state, performance limits, diagnostics, power management and recovery" ], "out_of_scope": [ "The host computer and its complete operating system or network stack", "Network cables, transceivers and antennas as independently managed components", "Switches, routers and access points acting as separate network infrastructure", "Virtual interfaces implemented entirely in software", "End-to-end network services, routing policy and application performance", "Product lines and individual asset histories as separate catalogue entities" ], "distinguishing_features": [ "Provides a hardware transmit and receive path between a host and a network, rather than merely naming a software interface.", "Exposes a host control or data interface alongside network-facing communication functions; a connector or passive adapter alone does not qualify.", "Performs controller functions such as frame handling, buffering or host data transfer; a standalone physical-layer transceiver does not by itself establish this identity.", "Acts as a host network attachment, even when it includes switching or programmable processing; a standalone switch or router requires a different primary model.", "May be integrated into a motherboard or system-on-chip, so a removable expansion card is not a necessary recognition test." ], "characteristics": [ { "name": "Implementation and integration", "kind": "category", "unit_or_values": "Controller chip, motherboard-integrated controller, system-on-chip block, removable adapter", "why_it_matters": "Determines the physical boundary, replacement options and which supporting components are external." }, { "name": "Host attachment", "kind": "relation", "unit_or_values": "Host bus or internal interconnect, supported generation, lane count and negotiated configuration where applicable", "why_it_matters": "Determines host compatibility and possible data-transfer bottlenecks." }, { "name": "Network technology and media", "kind": "category", "unit_or_values": "Supported network families, media, connectors or radio bands, with applicable specification revisions", "why_it_matters": "Determines which peers and physical connections can establish a link." }, { "name": "Network interface count", "kind": "measurement", "unit_or_values": "Number of physical ports or radio interfaces, distinguished from logical interfaces and host functions", "why_it_matters": "Prevents physical connectivity from being inferred from software interface counts." }, { "name": "Link rate capabilities", "kind": "measurement", "unit_or_values": "Supported and negotiated bit/s per interface, with direction and operating mode", "why_it_matters": "Constrains transfer capacity without equating link rate with application throughput." }, { "name": "Frame size limits", "kind": "measurement", "unit_or_values": "Bytes, stating whether the value describes a frame, payload or host MTU", "why_it_matters": "Supports compatible configuration and interpretation of size-related drops." }, { "name": "Address identity", "kind": "state", "unit_or_values": "Permanent and effective link-layer addresses where applicable, including assignment origin", "why_it_matters": "Supports interface recognition while accounting for address overrides and randomisation." }, { "name": "Queue and offload capabilities", "kind": "category", "unit_or_values": "Transmit and receive queue limits; supported checksum, segmentation, steering, timestamping or other accelerations", "why_it_matters": "Determines which host workloads and configurations the hardware can support." }, { "name": "Software compatibility", "kind": "relation", "unit_or_values": "Controller revision linked to driver, firmware, operating system and supported feature combinations", "why_it_matters": "Separates hardware capability from functionality available in the installed environment." }, { "name": "Operational state", "kind": "state", "unit_or_values": "Enumeration, administrative enablement, link state, negotiated mode, power state and fault indicators recorded separately", "why_it_matters": "Distinguishes a disabled or sleeping controller from a failed device or disconnected link." }, { "name": "Traffic and error counters", "kind": "measurement", "unit_or_values": "Packets, bytes, drops and errors over a stated interval, with counter definitions and reset history", "why_it_matters": "Supports diagnosis without confusing accumulated history with current faults." }, { "name": "Power and thermal envelope", "kind": "measurement", "unit_or_values": "W and °C, qualified by operating mode, measurement location and manufacturer limits", "why_it_matters": "Constrains installation, sustained operation and power-saving choices." } ], "affordances": [ "Identify the controller and map its physical interfaces to host-visible devices.", "Check compatibility among the host attachment, driver, firmware, network medium and intended peer.", "Configure supported link modes, queues, frame limits and offloads within an authorised operating policy.", "Observe link transitions and traffic counters to investigate connectivity or packet-transfer faults.", "Assign supported hardware resources to workloads while checking isolation and ownership.", "Plan a supported reset, firmware update or replacement with its connectivity impact recorded." ] }, "sources": [], "structure": { "bundles": [ { "id": "controller-boundary", "name": "Controller boundary", "description": "Establish what hardware constitutes the controller and how it appears to the host.", "rationale": "A chip, adapter, port and operating-system interface are related but cannot be treated as interchangeable identities.", "layers": [ { "id": "hardware-composition", "name": "Hardware composition", "description": "Locate controller functions and their supporting physical components.", "findings": [ { "id": "controller-function-boundary", "name": "Controller function boundary", "description": "Record which host-transfer, frame-processing and physical-interface functions lie inside the modelled hardware boundary.", "questions": [ { "text": "Which components perform host data transfer and network frame handling?", "kind": "definition", "id": "controller-function-boundary-q01" }, { "text": "Are the physical-layer device, transceiver, antenna and connector integrated or separately managed?", "kind": "boundary", "id": "controller-function-boundary-q02" } ] } ] }, { "id": "host-device-mapping", "name": "Host device mapping", "description": "Relate physical hardware to enumerated devices and logical interfaces.", "findings": [ { "id": "identity-and-enumeration", "name": "Identity and enumeration", "description": "Capture evidence connecting controller identity, hardware revision, host functions and network interfaces.", "questions": [ { "text": "Which hardware identifiers and manufacturer records establish the controller and revision?", "kind": "provenance", "id": "identity-and-enumeration-q01" }, { "text": "How do physical ports or radios map to host functions and operating-system interfaces?", "kind": "boundary", "id": "identity-and-enumeration-q02" } ] } ] } ] }, { "id": "network-link", "name": "Network link", "description": "Describe compatible network attachments and the conditions for establishing a usable link.", "rationale": "A controller can be recognised by the host yet remain unable to communicate with the attached medium or peer.", "layers": [ { "id": "media-and-protocols", "name": "Media and protocols", "description": "Define the supported network technologies and physical connection requirements.", "findings": [ { "id": "attachment-compatibility", "name": "Attachment compatibility", "description": "Record supported network specifications and the components required to realise each attachment.", "questions": [ { "text": "Which network specifications, revisions and issuing bodies are explicitly supported by authoritative documentation?", "kind": "provenance", "id": "attachment-compatibility-q01" }, { "text": "Which media, transceivers or antennas are required, and what compatibility limits apply?", "kind": "boundary", "id": "attachment-compatibility-q02" } ] } ] }, { "id": "link-establishment", "name": "Link establishment", "description": "Separate supported link modes from configured and currently established modes.", "findings": [ { "id": "negotiation-and-link-state", "name": "Negotiation and link state", "description": "Record the evidence and prerequisites for a link, including technology-specific negotiation or association.", "questions": [ { "text": "What rate, duplex or radio mode is currently established, and which status evidence supports it?", "kind": "measurement", "id": "negotiation-and-link-state-q01" }, { "text": "Which controller settings and peer conditions must be satisfied to establish or restore the link?", "kind": "action", "id": "negotiation-and-link-state-q02" } ] } ] } ] }, { "id": "host-packet-path", "name": "Host packet path", "description": "Describe packet movement between host memory and network interfaces.", "rationale": "Host interconnects, queues and acceleration features determine usable capacity and explain faults that link status alone cannot reveal.", "layers": [ { "id": "transfer-and-buffering", "name": "Transfer and buffering", "description": "Capture host transfer mechanisms, queues and packet-size constraints.", "findings": [ { "id": "data-path-capacity", "name": "Data path capacity", "description": "Record constraints that can limit packet transfer independently of nominal network rate.", "questions": [ { "text": "What host interconnect configuration, queue counts and buffer limits are supported and currently active?", "kind": "measurement", "id": "data-path-capacity-q01" }, { "text": "What frame or payload sizes are accepted, and how are oversize frames and exhausted buffers handled?", "kind": "definition", "id": "data-path-capacity-q02" } ] } ] }, { "id": "hardware-acceleration", "name": "Hardware acceleration", "description": "Describe optional packet-processing work performed by the controller.", "findings": [ { "id": "offload-availability", "name": "Offload availability", "description": "Distinguish advertised hardware features from features exposed and enabled by the installed software.", "questions": [ { "text": "Which offloads, receive-steering functions and timestamping capabilities are documented for this revision?", "kind": "provenance", "id": "offload-availability-q01" }, { "text": "Which features can be enabled for the intended workload, and what dependencies or incompatibilities constrain them?", "kind": "action", "id": "offload-availability-q02" } ] } ] } ] }, { "id": "control-and-isolation", "name": "Control and isolation", "description": "Describe configuration authority, address handling and separation of controller resources.", "rationale": "Controller settings affect traffic visibility, host access and workload separation, especially when hardware is shared or assigned directly.", "layers": [ { "id": "addressing-and-filtering", "name": "Addressing and filtering", "description": "Capture interface identities and hardware decisions about accepted or classified traffic.", "findings": [ { "id": "effective-receive-policy", "name": "Effective receive policy", "description": "Record effective link-layer addresses and supported receive filters without assuming they provide complete network security.", "questions": [ { "text": "Which addresses are permanent, assigned or overridden, and which are effective now?", "kind": "provenance", "id": "effective-receive-policy-q01" }, { "text": "Who may change address, multicast, VLAN or promiscuous-mode settings, and what traffic exposure would change?", "kind": "action", "id": "effective-receive-policy-q02" } ] } ] }, { "id": "resource-assignment", "name": "Resource assignment", "description": "Describe ownership of host functions, queues and any virtualised hardware resources.", "findings": [ { "id": "sharing-and-memory-access", "name": "Sharing and memory access", "description": "Record supported sharing mechanisms and the platform controls required for safe direct hardware access.", "questions": [ { "text": "Can the controller expose independently assignable functions or queues, and which resources remain shared?", "kind": "boundary", "id": "sharing-and-memory-access-q01" }, { "text": "What platform isolation and access controls are required before assigning the controller or a function to a workload?", "kind": "action", "id": "sharing-and-memory-access-q02" } ] } ] } ] }, { "id": "health-and-lifecycle", "name": "Health and lifecycle", "description": "Assess faults, operating limits and supported interventions across controller service life.", "rationale": "A down link, driver failure, power transition and hardware fault require different evidence and recovery actions.", "layers": [ { "id": "diagnostic-evidence", "name": "Diagnostic evidence", "description": "Relate observable controller state and counters to plausible fault locations.", "findings": [ { "id": "fault-localisation", "name": "Fault localisation", "description": "Record symptoms and diagnostic evidence while separating controller faults from host, medium and peer faults.", "questions": [ { "text": "Which errors, drops, resets or link transitions occurred over the observation interval, and how are their counters defined?", "kind": "measurement", "id": "fault-localisation-q01" }, { "text": "Which supported diagnostics can distinguish controller, driver, cable or radio, and peer-side problems?", "kind": "action", "id": "fault-localisation-q02" } ] } ] }, { "id": "service-and-power-transitions", "name": "Service and power transitions", "description": "Capture maintenance dependencies, operating limits and the effects of disruptive actions.", "findings": [ { "id": "supported-recovery", "name": "Supported recovery", "description": "Record evidence for supported power changes, resets, firmware updates and replacement procedures.", "questions": [ { "text": "Which power and temperature limits, driver-firmware combinations and recovery procedures are documented for the hardware revision?", "kind": "provenance", "id": "supported-recovery-q01" }, { "text": "What connectivity, shared-function and remote-management effects must be accounted for before sleep, reset, update or replacement?", "kind": "action", "id": "supported-recovery-q02" } ] } ] } ] }, { "id": "evidence-and-external-alignment", "name": "Evidence and external alignment", "description": "What the world already says about this thing, gathered so the model can be checked against it.", "rationale": "A model that cannot be lined up against existing standards, identifiers and practice cannot be adopted by anyone who already uses them.", "layers": [ { "id": "reported-evidence", "name": "Reported evidence", "description": "Findings from the breadth pass, kept separate from the structural claims.", "findings": [ { "id": "evidence-confidence-notes", "name": "Check these first", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Controller, adapter, and card are frequently used interchangeably; confirm whether the registry intends the controller chip or the complete hardware interface.", "Measurement ranges are illustrative recall, not researched market statistics; link rate differs from application throughput, and MTU is a configuration parameter.", "Applicable standards depend on the network medium and host interface; wireless capabilities and regulatory limits require product-specific verification." ], "questions": [ { "id": "evidence-confidence-notes-q01", "text": "Which of these check these first hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-kinds", "name": "Kinds and varieties", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Ethernet controller", "Wireless LAN controller", "Integrated motherboard network interface", "Expansion-card network interface", "USB network adapter", "SmartNIC with programmable processing or hardware offload" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-identifiers", "name": "Identifiers and schemes", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "scheme": "IEEE EUI-48 / MAC address", "value_or_pattern": "48 bits, commonly displayed as six hexadecimal octets", "note": "Commonly identifies an Ethernet or Wi-Fi interface; an assigned hardware address may be overridden or randomized, and one controller can expose multiple interfaces." }, { "scheme": "PCI vendor and device identifiers", "value_or_pattern": "16-bit vendor ID and 16-bit device ID", "note": "Identify PCI or PCI Express controller implementations for enumeration and driver matching, rather than individual physical units." }, { "scheme": "USB vendor and product identifiers", "value_or_pattern": "16-bit VID and 16-bit PID", "note": "Identify USB adapter implementations; they are not normally unique serial identifiers." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-standards-and-regulation", "name": "Standards and regulation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "IEEE 802.3, issued by IEEE: Ethernet MAC and physical-layer specifications.", "IEEE 802.11, issued by IEEE: wireless LAN MAC and physical-layer specifications.", "PCI Express specifications, issued by PCI-SIG: host interconnection for applicable controllers.", "USB specifications, issued by the USB Implementers Forum: host interconnection for applicable adapters." ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-real-world-use", "name": "Real-world use", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Connecting desktop and laptop computers to wired or wireless local-area networks.", "Connecting servers to data-centre networks.", "Providing network connectivity for embedded systems and industrial equipment.", "Providing separate network ports for routing, firewalling, or traffic isolation.", "Offloading selected packet-processing operations from the host CPU." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-measurements", "name": "Typical measurements", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "quantity": "Nominal Ethernet link rate", "typical_range": "1-10 for many desktop and workstation interfaces; 10-400 for many server interfaces", "unit": "Gbit/s" }, { "quantity": "Physical port count on Ethernet adapter cards", "typical_range": "1-4", "unit": "ports" }, { "quantity": "Common Ethernet IP maximum transmission unit", "typical_range": "1500 conventionally; approximately 9000 where jumbo frames are supported and configured", "unit": "bytes" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-failure-modes-and-hazards", "name": "Failure modes and hazards", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Cable, connector, transceiver, or radio-link faults can cause link loss, packet errors, or intermittent connectivity.", "Driver or firmware defects can cause crashes, stalled transmit queues, or incorrect packet processing.", "Receive-buffer exhaustion or host-bus bottlenecks can cause packet drops and reduced throughput.", "Overheating, electrostatic discharge, or electrical surges can damage the controller or its ports.", "Vulnerable firmware or inadequately isolated direct memory access can expose the host to security compromise." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-regional-variation", "name": "Regional variation", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ "Wireless interfaces have country-dependent permitted channels, frequency bands, and transmit-power limits." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] }, { "id": "evidence-neighbours", "name": "Neighbouring kinds and how to tell them apart", "description": "Recalled without web access and unsourced; every item is a lead to verify.", "evidence": [ { "name": "Network interface card", "difference": "Strictly denotes a physical card containing a controller and supporting components; a controller can instead be integrated into a motherboard or chip, although the terms are often used interchangeably." }, { "name": "Network transceiver", "difference": "Converts between electrical, optical, or radio signals and a physical link; it does not by itself provide the controller's complete host-facing network interface." }, { "name": "Network switch", "difference": "Forwards traffic among network ports, whereas a controller primarily attaches a host to a network." }, { "name": "Device driver", "difference": "Is software that operates the controller, rather than the networking hardware itself." }, { "name": "Virtual network interface", "difference": "Is a software-visible interface that need not correspond to a dedicated physical controller." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of network interface controller this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does the registry intend this entry to include wireless network controllers and modem-integrated network adapters, or are those owned by neighbouring entries?", "Where should the boundary fall between a network interface controller and a programmable SmartNIC or data processing unit with independent compute functions?", "Which existing Vercy models already own physical-layer transceivers, network adapters and virtual interfaces, and how should this entry link to them?", "Which authoritative specifications and manufacturer documents should establish technology-specific capabilities, diagnostics and operating limits?", "Should physical dimensions, replaceable components and certification evidence attach to the controller chip, complete adapter or both when those boundaries differ?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 19, "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 network interface controller, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an agent to recognise a network interface controller, assess its connectivity and operating state, and determine compatible and authorised configuration, use and maintenance 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: converged network adapter, data processing unit, RTL8153, TP-Link UE300, wired network adapter, wireless network adapter, wireless network interface controller, NE1000, 3Com 3c509, TP-LINK TL-WN822N v1, Killer NIC, Kedron.", "16 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 59 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 network interface controller, 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": [ "converged network adapter", "data processing unit", "RTL8153", "TP-Link UE300", "wired network adapter", "wireless network adapter", "wireless network interface controller", "NE1000", "3Com 3c509", "TP-LINK TL-WN822N v1", "Killer NIC", "Kedron" ] } ], "standing": "Described in 59 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 16 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 network interface controller from another, and a network interface controller 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 network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller 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 network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller 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 network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller 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 network interface controller is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller 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 network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller 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 network interface controller between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a network interface controller 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 network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller 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 network interface controller 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 network interface controller, 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 network interface controller 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 network interface controller 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 network interface controller 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 network interface controller 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 network interface controller 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 network interface controller, 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 network interface controller 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 network interface controller and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a network interface controller, 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 network interface controller, 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 network interface controller 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 network interface controller is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a network interface controller, 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 network interface controller, 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 network interface controller 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 } } } }