hard disk
Enable an AI agent to recognise a hard disk drive, assess its compatibility, condition and data exposure, and decide whether it may be connected, used, recovered, sanitised or retired.
Research draft, second pass
A second pass drafted this model: the structure a model of this thing needs, and what is known about it in the world. The line under this one says how the second half was obtained - researched against sources, or recalled without web access, in which case nothing here was read anywhere and every claim is a lead to verify. Unreviewed either way.
Researched by: Codex
Purpose and description
Enable an AI agent to recognise a hard disk drive, assess its compatibility, condition and data exposure, and decide whether it may be connected, used, recovered, sanitised or retired.
It can be Identify and interrogate the drive through a compatible connection while recording the observation path.; Mount, power and operate the drive within its documented mechanical, electrical and environmental limits.; Read or image addressable sectors, choosing an access strategy appropriate to the condition and recovery priority.; Write, overwrite or run diagnostic operations when authorised and justified by the drive's condition.; Isolate suspected drive failures from enclosure, cable, controller and power faults.; Sanitise, reuse, transfer or retire the drive using a supported method and explicit completion evidence..
Distinguishing features
Identify rotating magnetic platters and a head-positioning mechanism through reliable product identification or existing inspection evidence; an SSD lacks this recording mechanism.
Distinguish the complete drive, with recording assembly and control electronics, from a bare magnetic platter or replacement circuit board.
Distinguish an HDD inside an external enclosure from the enclosure and bridge that expose it to the host; a USB connection alone does not identify the internal medium.
Confirm that the device uses magnetic disks rather than a removable optical disc or magnetic tape; a drive letter or block-device interface alone is insufficient.
For a hybrid drive, establish whether rotating magnetic media provide persistent bulk storage and record any flash component separately.
Scope
+ Drive identity and evidence that its recording medium is rotating magnetic platters
+ Physical, electrical and command-interface compatibility
+ Addressable capacity, sector presentation and recording behaviour
+ Mechanical condition, diagnostic evidence and read/write reliability
+ Drive-level access restrictions, data exposure and lifecycle actions
- Filesystem, partition and file semantics, owned by logical storage models
- RAID membership policy, redundancy and array reconstruction, owned by storage-array models
- External enclosure, USB bridge and host-controller design, owned by their device models
- Meaning, ownership and retention policy of stored information, owned by information and governance models
- Host operating-system configuration and application performance, owned by host and workload models
Characteristics
- Drive identity
- Manufacturer, model, serial number and firmware revision; unknown or conflicting evidence allowed Connects observations, specifications and action history to the correct physical drive.
- Recording architecture
- Conventional magnetic recording, shingled magnetic recording with management mode, other documented architecture, or unknown Affects host compatibility, sustained-write behaviour and permissible command assumptions.
- Physical envelope
- Width, depth and height in mm; mass in g Determines whether a particular bay or enclosure can accommodate the drive.
- Connection and power requirements
- Observed connector, documented protocol, required supply rails and startup demand Prevents connections based only on connector resemblance and supports safe power provisioning.
- Exposed capacity
- Addressable logical-block count and calculated bytes, with observation path and timestamp Separates host-visible capacity from label claims and detects presentation changes.
- Sector presentation
- Logical and reported physical sector sizes in bytes Affects alignment, imaging, migration and compatibility.
- Rotational speed
- rpm, supported by device or manufacturer evidence; unknown permitted Helps interpret expected latency and mechanical operating behaviour.
- Mechanical operating state
- Unpowered, starting, spinning, standby, failing to spin, abnormal behaviour, or unknown Guides whether further power cycles or access attempts are appropriate.
- Media and diagnostic condition
- Timestamped errors, diagnostic results and counter trends with vendor-specific interpretation Supports evidence-based decisions without treating one health flag as proof of reliability.
- Operating temperature
- Degrees Celsius, sensor source and timestamp Allows comparison with documented limits and investigation of thermal problems.
- Connection path
- Host, controller, bridge, enclosure and physical port through which the drive is observed Separates drive faults from power, transport and command-translation faults.
- Access and sanitisation state
- Reported lock and encryption states, sanitisation method, completion evidence and verification limits Constrains access, recovery, reuse and transfer decisions.
Also called
Where this came from
wikidata · CC0 1.0
Drafted structure
Bundle to layer to finding to question, as the second pass will find it: 5 bundles · 10 layers · 10 findings · 20 questions.
Drive identity and boundary Establishes which physical magnetic storage device is being modelled and separates it from surrounding storage components.
Host-visible names and enclosure labels can conceal the underlying drive or incorrectly identify the object being acted upon.
Recording device identification
Determines whether the object is a complete HDD and identifies its recording architecture.
Magnetic drive evidence
Records evidence for a rotating magnetic recording assembly and any hybrid storage components.
- What evidence identifies this object as a complete hard disk drive rather than an SSD, bare platter or external enclosure? definition
- Which label, device response or manufacturer document establishes its recording architecture? provenance
Physical and reported identity
Reconciles the drive's physical markings with identities exposed through its connection path.
Identity reconciliation
Associates model, serial and firmware evidence with the physical drive while preserving discrepancies.
- Do the physical label and device-reported model and serial number agree, and when were they observed? provenance
- Which reported identifiers belong to the drive, and which belong to a bridge, enclosure or logical volume? boundary
Installation and operating envelope Captures the conditions required to connect, mount and operate this drive.
An HDD needs suitable startup power and mechanical support as well as a compatible data interface.
Connection and power
Establishes electrical and protocol compatibility across the actual connection path.
Supported connection path
Records connectors, protocol, power requirements and intermediary devices affecting access.
- Which data protocol, connectors, supply rails and startup power requirements are documented for this drive? definition
- Can the proposed host, adapter and power supply meet those requirements and pass the commands needed for the intended action? action
Mechanical and thermal conditions
Relates installation and handling to the drive's documented operating limits.
Installation suitability
Assesses fit, mounting, cooling and exposure to shock or vibration.
- What are the drive's dimensions, mounting requirements and documented operating and non-operating environmental limits? measurement
- Does the proposed installation or transport method satisfy those limits for the drive's powered or unpowered state? action
Media presentation and I/O behaviour Describes the storage the drive exposes and the recording behaviours relevant to using it.
Capacity alone does not establish whether an HDD can support a host's addressing assumptions or intended write pattern.
Addressable media
Records host-visible capacity and sector geometry without owning partitions or filesystems.
Capacity and sector evidence
Captures measured block presentation and discrepancies across labels or connection paths.
- How many logical blocks are exposed, and what logical and physical sector sizes does the drive report? measurement
- Are capacity discrepancies attributable to units, drive configuration, inaccessible regions or an intermediary device, and what remains unexplained? boundary
Recording and write semantics
Captures recording constraints, caching and completion behaviour relevant to actual workloads.
Workload and persistence constraints
Connects documented drive behaviour to write compatibility and evidence of durable completion.
- What evidence establishes conventional or shingled recording, any host-managed zones, and the supported cache and flush behaviour? provenance
- What must the host do for the intended write pattern and durability requirement, given the drive and connection path? action
Condition and recovery triage Combines mechanical symptoms, diagnostic history and access results to guide further interaction.
Repeated tests or power cycles may consume a failing drive's remaining opportunity for recovery.
Condition evidence
Records observed symptoms and diagnostic trends with their interpretation limits.
Mechanical and media observations
Preserves startup behaviour, abnormal sounds, read failures and health telemetry as distinct observations.
- What startup behaviour, abnormal sounds, temperatures, read errors and diagnostic results have been observed, and how have they changed? measurement
- Which diagnostic meanings are documented for this model and firmware, and which interpretations remain uncertain? provenance
Fault isolation and access strategy
Separates likely drive faults from connection faults and selects a justified next operation.
Least damaging next access
Records recovery priorities, existing copies, stop conditions and the justification for further access.
- What evidence separates media or mechanical failure from cable, controller, bridge or power faults? boundary
- Given the symptoms, data-recovery priority and available copies, should access stop, proceed with controlled imaging, or move to specialist recovery? action
Access control and disposition Records drive-level access restrictions and evidence needed for sanitisation, transfer or retirement.
A drive can be unreadable yet retain data, and a reported erase completion may not establish the required sanitisation outcome.
Drive-level access state
Identifies device locks and encryption boundaries without storing credentials in the model.
Locks and encryption boundaries
Distinguishes drive-enforced restrictions from enclosure or host encryption and records authorised access paths.
- Which locks or encryption mechanisms are evidenced, and are they enforced by the drive, enclosure or host? boundary
- What authorised credential or key-management reference is needed for access, and what consequences would unlocking, resetting or key removal have? action
Sanitisation and release
Connects the intended disposition to supported sanitisation methods and verifiable outcomes.
Disposition evidence
Records method support, execution results, coverage limits and the basis for releasing or retiring the drive.
- Which sanitisation methods are supported through this connection path, and what evidence establishes their coverage of remapped or otherwise inaccessible media? provenance
- What authorisation, completion and verification evidence is required before this drive may be reused, transferred or destroyed? action
What the second pass must settle
- Does the registry intend 'hard disk' to mean the complete HDD, the magnetic recording medium, or both, and is an existing world model already authoritative for that concept?
- Should hybrid drives fall wholly within this entry or be represented through a relationship to a separate flash-storage component model?
- Which manufacturer and protocol sources are needed to interpret recording mode, diagnostic attributes and command support without unreliable inference from model names?
- What evidence is sufficient to distinguish drive failure from connection-path failure while limiting further stress on a drive containing the only available copy of data?
- Which sanitisation assurance requirements apply to each disposition, and how should unavailable evidence about inaccessible media or encryption keys constrain release?