{ "model": { "rank": 6048, "code": "thing-q487343", "model_id": "vr.tr.solid-state-drive", "name": "solid-state drive", "purpose": "Enable an AI agent to recognise a solid-state drive, assess its compatibility, data integrity and remaining serviceability, and choose justified maintenance, reuse or retirement 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/q487343/", "tier": 2, "score": 63, "payload": { "layer": "wikidata", "aliases": [ "embedded MultiMediaCard", "WD Blue SATA SSD", "DRAMless SSD" ], "aliasCount": 3, "merged": 3, "knownIn": 63, "facets": null, "markers": [], "lexicalClass": "", "senseRank": null, "alsoRegisteredAs": null, "source": { "dataset": "wikidata", "item": "Q487343", "url": "https://www.wikidata.org/wiki/Q487343", "license": "CC0 1.0" } }, "research": { "vercy": "1.0-draft", "publication": { "status": "research-draft", "adjudicationStatus": "unreviewed", "publishableCanonical": false, "generatedAt": "2026-09-07T11:13:03Z", "providers": [ "Codex", "Grok" ], "missingProviders": [], "pass": 2, "cost": { "grok": { "usd": 0.00815048, "turns": 1, "seconds": 135.2, "error": null }, "codex": { "seconds": 72.1, "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: 01a07b8e-3f49-7ca1-88a3-7105ec322500\n--------\nuser\nYou are drafting a Vercy meta-model for one registered thing. Answer as JSON only, no prose around it.\n\nThing: solid-state drive\nRegistry id: vr.tr.solid-state-drive\nPlane / domain: PHY / PHY.OBJ\nRegistry definition: (none recorded)\nNames folded into this entr" } } }, "metaModel": { "id": "THING-Q487343", "registryId": "vr.tr.solid-state-drive", "name": "solid-state drive", "version": "0.1.0-research.1", "entryKind": "thing", "family": "Thing Registry", "domain": [ "PHY.OBJ" ], "status": "research-draft" }, "canonicalUrl": "https://ver.cy/models/thing/q487343/", "model": { "registry_id": "vr.tr.solid-state-drive", "name": "solid-state drive", "purpose": "Enable an AI agent to recognise a solid-state drive, assess its compatibility, data integrity and remaining serviceability, and choose justified maintenance, reuse or retirement actions.", "definition": "A solid-state drive is a non-volatile block-storage device that persists host data in semiconductor memory - almost always NAND flash, historically also 3D XPoint - and presents that data through a storage-host protocol (NVMe/PCIe, SATA/AHCI, or SAS) without rotating platters or a head-actuator assembly.", "scope_statement": "This model owns the physical solid-state storage device, its controller-mediated persistent storage, host-facing capabilities, observable condition and device-level operations; it records dependencies on host systems and data policies without owning those systems or policies.", "in_scope": [ "Device identity, storage technology and physical boundaries", "Mechanical, electrical and host-protocol compatibility", "Exposed capacity, addressable storage and supported device commands", "Firmware, health evidence, endurance and failure symptoms", "Device-level protection, sanitisation, servicing and disposition" ], "out_of_scope": [ "Filesystem organisation, files and application-level data meaning", "Host operating-system configuration and motherboard design", "Storage-array redundancy, pooling and distributed replication", "Backup contents, recovery-point policy and retention obligations", "Manufacturing processes for semiconductor dies" ], "distinguishing_features": [ "Confirm that persistent storage uses solid-state media without rotating magnetic platters; a hybrid drive containing flash and platters does not pass this boundary test.", "Confirm that the identified thing includes controller-managed, host-accessible storage rather than being a bare memory chip or volatile RAM module.", "Separate physical-device identity from exposed namespaces, partitions and logical volumes; these can represent portions or combinations of devices rather than individual SSDs.", "Use the declared device class, controller and intended storage role to distinguish an SSD from a memory card or USB flash drive; semiconductor storage or a USB connection alone does not settle the distinction.", "Check storage protocol and controller identity in addition to physical shape; an M.2-shaped module is not sufficient evidence that the object is an SSD." ], "characteristics": [ { "name": "Device identity", "kind": "category", "unit_or_values": "Manufacturer, model, serial identifier and hardware revision, with unknown values explicit", "why_it_matters": "Connects observations, compatibility evidence and maintenance instructions to the correct physical device." }, { "name": "Storage medium", "kind": "category", "unit_or_values": "Declared nonvolatile medium and, where documented, cell technology; otherwise unknown", "why_it_matters": "Prevents unsupported assumptions about endurance, retention and operating behaviour." }, { "name": "Physical and electrical fit", "kind": "category", "unit_or_values": "Form factor, dimensions, connector, keying and documented supply requirements", "why_it_matters": "Determines whether installation is mechanically and electrically supported." }, { "name": "Host communication path", "kind": "relation", "unit_or_values": "Device interface and protocol linked to host port, adapter or bridge and negotiated connection", "why_it_matters": "Explains accessibility, performance limits and commands or health information hidden by intermediaries." }, { "name": "Exposed storage geometry", "kind": "measurement", "unit_or_values": "Host-addressable bytes, logical block size in bytes and capacity per exposed namespace or equivalent unit", "why_it_matters": "Supports capacity checks and distinguishes physical-device limits from logical allocation." }, { "name": "Firmware revision", "kind": "category", "unit_or_values": "Reported revision and applicable vendor release evidence", "why_it_matters": "Helps assess documented defects, supported features and update applicability." }, { "name": "Workload performance", "kind": "measurement", "unit_or_values": "MB/s, operations/s and latency in milliseconds, with workload, queue depth, fill level and test duration", "why_it_matters": "Makes performance observations interpretable and avoids treating peak ratings as sustained behaviour." }, { "name": "Thermal condition", "kind": "state", "unit_or_values": "Reported temperature in degrees Celsius, sensor identity, documented limits and throttling indication", "why_it_matters": "Supports cooling decisions and interpretation of performance changes." }, { "name": "Endurance evidence", "kind": "measurement", "unit_or_values": "Reported writes with counter units, wear indicators with vendor meaning and documented endurance rating", "why_it_matters": "Supports a qualified wear assessment without treating a rating or counter as a guaranteed failure date." }, { "name": "Integrity and availability condition", "kind": "state", "unit_or_values": "Readable, writable, read-only, intermittently accessible, inaccessible or unknown, with error evidence and timestamps", "why_it_matters": "Determines whether continued use, evidence preservation or recovery should take priority." }, { "name": "Protection and sanitisation condition", "kind": "state", "unit_or_values": "Documented encryption capability, lock state, sanitisation support and last verified operation outcome", "why_it_matters": "Separates supported security features from demonstrated protection or removal of stored data." } ], "affordances": [ "Identify and inventory the physical drive and its exposed storage units.", "Assess installation or migration compatibility against a specific host connection.", "Read supported health logs and run bounded diagnostics appropriate to the drive's condition.", "Provision supported storage settings or update firmware when prerequisites and authority are established.", "Prioritise data preservation and replace or retire a drive using observed condition and workload requirements.", "Perform an authorised, supported sanitisation operation and record its completion evidence and limitations." ] }, "sources": [ { "id": "wikipedia-ssd", "title": "Solid-state drive - Wikimedia Foundation (Wikipedia)", "url": "https://en.wikipedia.org/wiki/Solid-state_drive", "what_it_supports": "Common definition, interfaces and form factors, distinction from HDDs and USB flash, typical consumer and enterprise uses.", "url_status": "live" }, { "id": "jedec-jesd218", "title": "JESD218: Solid-State Drive (SSD) Requirements and Endurance Test Method - JEDEC Solid State Technology Association", "url": "", "what_it_supports": "Industry definition of SSD endurance testing, TBW/DWPD framing, and client versus enterprise workload assumptions." }, { "id": "nvme-base", "title": "NVM Express Base Specification - NVM Express, Inc.", "url": "https://nvmexpress.org/specifications/", "what_it_supports": "The dominant host protocol for PCIe SSDs, including Identify, namespaces, and NGUID/EUI-64 naming of namespaces.", "url_status": "live" }, { "id": "nist-800-88", "title": "NIST Special Publication 800-88 Revision 1, Guidelines for Media Sanitization - National Institute of Standards and Technology", "url": "", "what_it_supports": "Why SSD sanitization differs from HDD overwrite, and crypto-erase / block-erase practice in regulated settings." } ], "structure": { "bundles": [ { "id": "device-identity-and-boundary", "name": "Device identity and boundary", "description": "Establish which physical storage device is being modelled and which logical or packaged components belong to it.", "rationale": "An agent must avoid confusing an SSD with its enclosure, a memory component or a logical storage allocation.", "layers": [ { "id": "storage-device-classification", "name": "Storage device classification", "description": "Determine whether the thing meets the registry boundary for a solid-state drive.", "findings": [ { "id": "controller-managed-solid-state-storage", "name": "Controller-managed solid-state storage", "description": "Record evidence for persistent solid-state media, controller mediation and the declared device class.", "questions": [ { "text": "What device documentation or observations establish that this is a solid-state drive rather than RAM, a bare memory chip or a hybrid disk?", "kind": "definition", "id": "controller-managed-solid-state-storage-q01" }, { "text": "What boundary distinguishes this device from adjacent flash-storage classes such as memory cards and USB flash drives?", "kind": "boundary", "id": "controller-managed-solid-state-storage-q02" } ] } ] }, { "id": "physical-and-logical-identity", "name": "Physical and logical identity", "description": "Link persistent device identity to the storage units and packaging visible to the agent.", "findings": [ { "id": "drive-and-exposed-unit-mapping", "name": "Drive and exposed unit mapping", "description": "Record how identifiers, namespaces or equivalent units, and any enclosure map to the physical SSD.", "questions": [ { "text": "Which identifiers came from the drive itself, and which came from a bridge, enclosure or host inventory?", "kind": "provenance", "id": "drive-and-exposed-unit-mapping-q01" }, { "text": "Which exposed storage units belong to this physical SSD, and which represent partitions, pooled storage or virtual devices?", "kind": "boundary", "id": "drive-and-exposed-unit-mapping-q02" } ] } ] } ] }, { "id": "host-fit-and-storage-exposure", "name": "Host fit and storage exposure", "description": "Describe how the SSD can connect to a host and what addressable storage it presents.", "rationale": "Matching a connector or advertised capacity does not establish usable installation compatibility.", "layers": [ { "id": "connection-compatibility", "name": "Connection compatibility", "description": "Assess the complete mechanical, electrical and protocol path.", "findings": [ { "id": "supported-host-path", "name": "Supported host path", "description": "Record device requirements, host support and any adapter constraints.", "questions": [ { "text": "Do the target slot, mounting space, connector, supply and supported protocol match the documented requirements of this SSD?", "kind": "boundary", "id": "supported-host-path-q01" }, { "text": "What connection was negotiated, and does any adapter or bridge restrict bandwidth, management commands or health visibility?", "kind": "measurement", "id": "supported-host-path-q02" } ] } ] }, { "id": "addressable-capacity", "name": "Addressable capacity", "description": "Distinguish advertised storage from currently exposed and usable device capacity.", "findings": [ { "id": "capacity-and-block-format", "name": "Capacity and block format", "description": "Record host-addressable capacity, block format and exposed unit configuration without inferring hidden physical capacity.", "questions": [ { "text": "What capacity and logical block size does each exposed storage unit report, and how do these relate to the device's advertised capacity?", "kind": "measurement", "id": "capacity-and-block-format-q01" }, { "text": "Which supported capacity, namespace or block-format changes are available, and which would destroy data or require host reconfiguration?", "kind": "action", "id": "capacity-and-block-format-q02" } ] } ] } ] }, { "id": "workload-and-operating-behaviour", "name": "Workload and operating behaviour", "description": "Relate observed performance to workload, occupancy, thermal state and power conditions.", "rationale": "An SSD can remain accessible while its operating conditions make it unsuitable for the intended workload.", "layers": [ { "id": "sustained-workload-response", "name": "Sustained workload response", "description": "Capture performance under stated conditions and distinguish short bursts from sustained operation.", "findings": [ { "id": "performance-with-test-context", "name": "Performance with test context", "description": "Record throughput and latency together with the workload and drive state needed to interpret them.", "questions": [ { "text": "What throughput and latency were observed for a stated read/write mix, access pattern, block size, queue depth, fill level and duration?", "kind": "measurement", "id": "performance-with-test-context-q01" }, { "text": "What evidence separates device limitations from host-path bottlenecks, caching effects or background drive activity?", "kind": "provenance", "id": "performance-with-test-context-q02" } ] } ] }, { "id": "thermal-and-power-response", "name": "Thermal and power response", "description": "Assess operating limits and documented behaviour during power transitions or interruption.", "findings": [ { "id": "operating-envelope-and-interruption", "name": "Operating envelope and interruption", "description": "Record thermal observations, applicable limits and evidence about power-loss handling.", "questions": [ { "text": "Which temperature sensors and throttling indicators are available, and how do observations compare with documented operating limits?", "kind": "measurement", "id": "operating-envelope-and-interruption-q01" }, { "text": "What documented power-loss protection and cache-flush behaviour apply to this model, and what prerequisites govern safe shutdown or removal?", "kind": "action", "id": "operating-envelope-and-interruption-q02" } ] } ] } ] }, { "id": "wear-integrity-and-recovery", "name": "Wear, integrity and recovery", "description": "Interpret device health evidence and choose actions that preserve access to data.", "rationale": "Wear estimates, interface errors and media failures require different interpretations and interventions.", "layers": [ { "id": "endurance-and-health-evidence", "name": "Endurance and health evidence", "description": "Track wear and health indicators with their documented meanings and observation history.", "findings": [ { "id": "qualified-wear-assessment", "name": "Qualified wear assessment", "description": "Relate write counters and wear indicators to applicable ratings without presenting them as precise remaining lifetime.", "questions": [ { "text": "What are the units, reset behaviour and documented meanings of the available write, wear and spare-capacity indicators?", "kind": "provenance", "id": "qualified-wear-assessment-q01" }, { "text": "How have these indicators changed over time, and which documented endurance rating and workload assumptions apply?", "kind": "measurement", "id": "qualified-wear-assessment-q02" } ] } ] }, { "id": "failure-triage-and-preservation", "name": "Failure triage and preservation", "description": "Assess access failures and decide whether diagnostics, copying or specialist recovery should come first.", "findings": [ { "id": "access-condition-and-next-safe-step", "name": "Access condition and next safe step", "description": "Record read/write accessibility, error evidence and the effect of proposed actions on recoverability.", "questions": [ { "text": "Which observations distinguish media or controller trouble from a cable, power, bridge or host-path fault, and what remains unresolved?", "kind": "measurement", "id": "access-condition-and-next-safe-step-q01" }, { "text": "Given data value, available copies and current accessibility, should the next action be bounded diagnosis, data preservation, isolation or specialist recovery?", "kind": "action", "id": "access-condition-and-next-safe-step-q02" } ] } ] } ] }, { "id": "firmware-protection-and-disposition", "name": "Firmware, protection and disposition", "description": "Control device-level changes and establish evidence for secure reuse or retirement.", "rationale": "Firmware changes, locking and sanitisation can alter accessibility or destroy data, so supported capability and verified outcome must remain distinct.", "layers": [ { "id": "firmware-and-access-control", "name": "Firmware and access control", "description": "Record firmware applicability and device-level protection dependencies.", "findings": [ { "id": "maintenance-and-unlock-prerequisites", "name": "Maintenance and unlock prerequisites", "description": "Identify supported maintenance operations, lock state and required authority without storing secret credentials in the model.", "questions": [ { "text": "Which vendor evidence links an available firmware update to this exact model and hardware revision, and what prerequisites or data risks are documented?", "kind": "provenance", "id": "maintenance-and-unlock-prerequisites-q01" }, { "text": "What device-level lock or encryption state is established, and what authorised credential or key-management dependency is required for the proposed operation?", "kind": "action", "id": "maintenance-and-unlock-prerequisites-q02" } ] } ] }, { "id": "sanitisation-and-reuse", "name": "Sanitisation and reuse", "description": "Select supported data-removal operations and assess whether their outcomes support the intended disposition.", "findings": [ { "id": "sanitisation-scope-and-completion", "name": "Sanitisation scope and completion", "description": "Record operation scope, connection support, completion evidence and unresolved coverage of inaccessible storage.", "questions": [ { "text": "Which sanitisation operations are supported through the current connection, and what documented coverage do they claim for allocated, deallocated, remapped and controller-reserved storage?", "kind": "boundary", "id": "sanitisation-scope-and-completion-q01" }, { "text": "What authorisation and completion evidence are required before reuse or disposal, and what alternative is appropriate if the drive cannot complete or verify the operation?", "kind": "action", "id": "sanitisation-scope-and-completion-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": [ "Client SATA SSD (typically 2.5-inch or mSATA)", "Client NVMe SSD (typically M.2, most often 2280)", "Enterprise SAS SSD", "Enterprise NVMe SSD (U.2, U.3, EDSFF, or PCIe add-in card)", "Portable USB SSD", "Industrial and embedded SSD (wide-temperature, often SLC or pSLC)", "QLC capacity-oriented SSD (read-intensive / cold data)", "Self-encrypting SSD (TCG Opal or FIPS-validated)" ], "questions": [ { "id": "evidence-kinds-q01", "text": "Which of these kinds and varieties hold for the sense of solid-state drive 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": "Q175538", "note": "Item for the device class solid-state drive." }, { "scheme": "NVMe namespace identifier", "value_or_pattern": "NGUID (16-byte) or EUI-64", "note": "Per-namespace unique identifier reported by an NVMe controller." }, { "scheme": "ATA Identify / SCSI inquiry", "value_or_pattern": "Model string + serial number", "note": "Host-visible product identity on SATA and SAS SSDs." }, { "scheme": "Manufacturer SKU / part number", "value_or_pattern": "Vendor-assigned P/N, often plus firmware revision", "note": "The unit sold in BOM and warranty records; firmware revision is part of the identity because behaviour changes with it." } ], "questions": [ { "id": "evidence-identifiers-q01", "text": "Which of these identifiers and schemes hold for the sense of solid-state drive 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": [ "JEDEC JESD218 and JESD219 - SSD endurance requirements and client/enterprise workloads (JEDEC)", "NVM Express Base Specification - PCIe SSD host command set (NVM Express, Inc.)", "Serial ATA Revision 3.x - SATA electrical and command interface (SATA-IO)", "SCSI / SAS command and transport standards - enterprise SAS SSDs (INCITS T10; SAS from SCSI Trade Association / INCITS)", "PCI Express Base Specification - physical and transaction layer under NVMe (PCI-SIG)", "TCG Storage Opal SSC - self-encrypting drive command class (Trusted Computing Group)", "NIST SP 800-88 Rev. 1 - media sanitization, including flash-specific methods (NIST)", "FIPS 140-2 / 140-3 - cryptographic module validation when an SSD is sold as a validated SED (NIST/CMVP)", "IEC 62368-1 - safety of ICT equipment that houses or is sold as a drive (IEC)", "EU RoHS Directive 2011/65/EU and WEEE Directive 2012/19/EU - restricted substances and end-of-life take-back for electronic storage devices" ], "questions": [ { "id": "evidence-standards-and-regulation-q01", "text": "Which of these standards and regulation hold for the sense of solid-state drive 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": [ "Primary boot and application volume in laptops and desktops, now usually an M.2 NVMe module on the motherboard.", "Cache or all-flash capacity in servers, NAS appliances, and all-flash arrays, using U.2/U.3, EDSFF, or SAS bays.", "Game consoles and handhelds as the internal game and OS store, often a soldered or proprietary NVMe module.", "Field and industrial machines as a wide-temperature 2.5-inch or mSATA/M.2 card for logging and images.", "Portable backup and media shuttle as a USB-enclosed NVMe or SATA bridge drive.", "Hot-spare and RAID member in datacenters, where endurance class (DWPD) and power-loss protection are specified in the purchase." ], "questions": [ { "id": "evidence-real-world-use-q01", "text": "Which of these real-world use hold for the sense of solid-state drive 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": "User-addressable capacity", "typical_range": "250 GB-4 TB consumer; 1.6-30 TB enterprise", "unit": "GB or TB (decimal, 10^9/10^12 bytes, as labelled)" }, { "quantity": "Sequential read throughput", "typical_range": "~500-550 (SATA); ~3000-3500 (PCIe 3.0 x4); ~5000-7500 (PCIe 4.0 x4); ~10000-14000 (PCIe 5.0 x4)", "unit": "MB/s or GB/s" }, { "quantity": "Random 4 KiB read IOPS", "typical_range": "~50e3-100e3 SATA client; ~300e3-2e6 NVMe client/enterprise", "unit": "IOPS" }, { "quantity": "Read latency (typical 4 KiB)", "typical_range": "20-150", "unit": "µs" }, { "quantity": "Endurance", "typical_range": "Client ~150-600 TBW per 1 TB; enterprise often 0.3-3 DWPD over 3-5 years", "unit": "TBW or DWPD" }, { "quantity": "Active power", "typical_range": "2-8 client NVMe/SATA; ~10-25 enterprise NVMe", "unit": "W" }, { "quantity": "Uncorrectable bit error rate (UBER)", "typical_range": "10^-15 to 10^-17 (class-dependent)", "unit": "errors per bit read" }, { "quantity": "Operating temperature (client)", "typical_range": "0-70 case, with throttling above ~70-80 controller", "unit": "°C" } ], "questions": [ { "id": "evidence-measurements-q01", "text": "Which of these typical measurements hold for the sense of solid-state drive 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": [ "NAND wear-out: program/erase cycles exhausted, rising bit errors, drive goes read-only or fails SMART endurance attributes.", "Sudden power loss without board-level capacitance: in-flight writes and mapping-table updates lost or inconsistent, especially on DRAM-less client drives.", "Firmware defects: bricking, performance collapse, or silent data loss after a specific command or garbage-collection path.", "Data retention loss: unpowered NAND at high temperature loses charge, so archived drives can become unreadable.", "Thermal throttling and, rarely, thermal runaway of the controller or power stage under sustained writes.", "Write-amplification and QLC/TLC performance cliffs after the SLC cache is full.", "Controller, DRAM, or power-component hardware failure independent of NAND life.", "Sanitization failure: block overwrite does not reliably erase all flash; residual user data may remain without crypto-erase or block erase.", "Counterfeit or relabelled drives reporting false capacity or endurance.", "Difficult forensic recovery relative to HDDs because of FTL indirection, encryption, and wear-leveling." ], "questions": [ { "id": "evidence-failure-modes-and-hazards-q01", "text": "Which of these failure modes and hazards hold for the sense of solid-state drive 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": [ "English marketing still sometimes says \"solid-state disk\" or \"hard disk\" for an SSD; specialists prefer \"drive\" because there is no disk.", "Mandarin product language is 固态硬盘 (gùtài yìngpán); Japanese and Korean markets likewise use the SSD loanword plus local \"SSD/solid disk\" retail labels.", "Consumer default form factor is globally M.2 2280 NVMe; 2.5-inch SATA remains common in NAS, optical-bay upgrades, and many enterprise trays.", "US and EU public-sector buys often require NIST 800-88 or equivalent sanitization and, for SEDs, FIPS 140 validation; those clauses are less common in consumer channels.", "China, Korea, Japan, and the US dominate NAND and controller supply, so firmware behaviour, SMART attribute layouts, and warranty terms follow vendor rather than a single regional code.", "In parts of South Asia and Latin America, \"pendrive\" or \"memoria\" may be used loosely for any semiconductor store, including USB SSDs." ], "questions": [ { "id": "evidence-regional-variation-q01", "text": "Which of these regional variation hold for the sense of solid-state drive 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": "Hard disk drive (HDD)", "difference": "An HDD stores bits on rotating magnetic platters with a moving head; seek/rotational latency is milliseconds and the device has acoustic and shock-sensitive mechanics. An SSD has no platters; latency is tens to hundreds of microseconds and identity is the semiconductor FTL plus host protocol." }, { "name": "USB flash drive (thumb drive)", "difference": "A thumb drive is a USB mass-storage gadget with a small controller and usually no DRAM, power-loss capacitors, or NVMe/SATA host stack. A USB SSD is a full SSD (often NVMe or SATA) in an enclosure with a bridge; endurance, SMART, and sustained-write behaviour follow SSD class, not gadget-flash class." }, { "name": "eMMC or UFS device", "difference": "eMMC/UFS are soldered package-on-package or BGA memories on a JEDEC/MIPI protocol for phones and boards, not a removable SATA/NVMe/SAS drive with a drive-bay or M.2 keying." }, { "name": "Solid-state hybrid drive (SSHD)", "difference": "An SSHD is an HDD with a small NAND cache; the capacity medium is still magnetic platters. If the bulk medium is only NAND (or other persistent semiconductor memory), it is an SSD." }, { "name": "NVDIMM / persistent memory", "difference": "Persistent memory sits on the memory bus (DDR) and is byte-addressable to the CPU. An SSD sits on a storage bus and is block-addressable via NVMe, SATA, or SAS." }, { "name": "SD / microSD memory card", "difference": "A memory card uses the SD Association protocol and a card form factor; it is not a host SSD protocol device and is specified to different endurance and command sets." } ], "questions": [ { "id": "evidence-neighbours-q01", "text": "Which of these neighbouring kinds and how to tell them apart hold for the sense of solid-state drive this model covers, and on what evidence?", "kind": "provenance" } ] } ] } ] } ] }, "openQuestions": [ "Does an existing Vercy world model already own this concept, requiring a registry link rather than a separate publication?", "Where does the registry draw the boundary between SSDs, embedded managed storage, memory cards and USB flash drives, including devices inside external enclosures?", "Which authoritative specifications and vendor documents establish the meanings and comparability of health, wear and error indicators across the SSD families covered?", "What model-specific evidence is required to assess power-loss protection, unpowered data retention and recovery limits without generalising across storage technologies?", "Which sanitisation methods and verification evidence satisfy the intended reuse or disposal requirements for each supported controller, firmware and connection path?" ], "statistics": { "bundles": 6, "layers": 11, "findings": 18, "questions": 28 } }, "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 solid-state drive, record what state it is in, and decide what may be done with it.", "whatItIs": "Enable an AI agent to recognise a solid-state drive, assess its compatibility, data integrity and remaining serviceability, and choose justified maintenance, reuse or retirement 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: embedded MultiMediaCard, WD Blue SATA SSD, DRAMless SSD.", "3 finer distinctions are held as aliases rather than separate entries, because telling them apart needs a task that asks for it.", "Described in 63 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 solid-state drive, 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": [ "embedded MultiMediaCard", "WD Blue SATA SSD", "DRAMless SSD" ] } ], "standing": "Described in 63 Wikipedia languages, which measures how widely it is written about rather than how important or how common it is. 3 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 solid-state drive from another, and a solid-state drive 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 solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive 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 solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive from the things most often confused with it.", "questions": [ { "id": "distinguishing-features-q01", "text": "What identifies and describes what distinguishes a solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive 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 solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive is built from and which parts are replaceable.", "questions": [ { "id": "parts-and-materials-q01", "text": "What identifies and describes the composition of a solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive is judged and by whom.", "questions": [ { "id": "condition-assessment-q01", "text": "What identifies and describes the condition of a solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive 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 solid-state drive is, and what that position is measured against.", "questions": [ { "id": "position-and-frame-q01", "text": "What identifies and describes the location of a solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive 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 solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive 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 solid-state drive between them.", "questions": [ { "id": "stages-and-transitions-q01", "text": "What identifies and describes the lifecycle of a solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive, how often and by whom.", "findings": [ { "id": "observation-record", "name": "Observation record", "description": "How an observation of a solid-state drive 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 solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive 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 solid-state drive 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 solid-state drive, 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 solid-state drive 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 solid-state drive 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 solid-state drive 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 solid-state drive 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 solid-state drive 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 solid-state drive, 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 solid-state drive 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 solid-state drive and how confident it is.", "questions": [ { "id": "claim-provenance-q01", "text": "What identifies and describes a claim about a solid-state drive, 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 solid-state drive, 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 solid-state drive 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 solid-state drive is retired without being erased.", "questions": [ { "id": "validity-and-supersession-q01", "text": "What identifies and describes the validity of a claim about a solid-state drive, 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 solid-state drive, 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 solid-state drive 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 } } } }