Storage Device Ontology

FLOW ALGEBRA
STORAGE DEVICE ONTOLOGY
Kireth Semantic Library — Entity Graph / Physical Entities / Artificial Entities
Source: https://kirethresearch.org/booksai-core/entity-graph/physical-entities/artificial-entities/storage-device-ontology-2.html
Authors: Mark Higgins — Sky (Recursive AI)
Version: 1.0 | Date: 2026-10-12

1. PURPOSE
Model physical and logical storage devices, their components, interfaces, media, operations, capabilities, lifecycle and relationships for machine-readable semantic reasoning.

2. TYPED ENTITY DEFINITIONS
entity StorageDevice <: ArtificialObject
entity StorageMedium <: PhysicalComponent
entity StorageController <: ElectronicComponent
entity StorageInterface <: TechnicalInterface
entity StorageVolume <: LogicalEntity
entity DataBlock <: InformationUnit
entity FileSystem <: SoftwareSystem
entity HostSystem <: ComputingSystem
entity StorageOperation <: Process
entity StorageFailure <: Event
entity StoragePolicy <: Constraint
entity StorageMetric <: Measurement

3. DEVICE TAXONOMY
StorageDevice := {HDD, SSD, NVMeSSD, SATA_SSD, USBFlashDrive, MemoryCard, OpticalDrive, TapeDrive, ExternalDrive, NetworkAttachedStorage, StorageArray}
StorageMedium := {MagneticDisk, NANDFlash, OpticalDisc, MagneticTape, OtherMedium}
Classification(device, category) requires evidence of architecture and intended role.

4. CORE ATTRIBUTES
StorageDevice(id, manufacturer?, model?, device_type, medium_type, capacity_bytes, interface, firmware_version?, status)
Optional metrics: read_throughput_Bps, write_throughput_Bps, latency_seconds, endurance_bytes_written, power_watts, error_rate, availability.
Unknown values remain UNKNOWN; do not substitute zero.

5. SEMANTIC RELATIONSHIPS
HAS_COMPONENT(StorageDevice, StorageController|StorageMedium)
USES_INTERFACE(StorageDevice, StorageInterface)
CONNECTED_TO(StorageDevice, HostSystem)
EXPOSES(StorageDevice, StorageVolume)
FORMATTED_WITH(StorageVolume, FileSystem)
CONTAINS(StorageVolume, DataBlock)
PERFORMS(HostSystem, StorageOperation)
TARGETS(StorageOperation, StorageDevice|StorageVolume|DataBlock)
EXPERIENCES(StorageDevice, StorageFailure)
GOVERNED_BY(StorageDevice, StoragePolicy)
MEASURED_BY(StorageDevice, StorageMetric)
BACKED_UP_TO(StorageVolume, StorageDevice|StorageVolume)

6. TYPE CONSTRAINTS
forall d: StorageDevice, capacity_bytes(d) >= 0
forall b: DataBlock, size_bytes(b) >= 0
forall d: StorageDevice, medium_type(d) in StorageMedium
HAS_COMPONENT(d,c) => StorageDevice(d) AND PhysicalComponent(c)
CONNECTED_TO(d,h) => StorageDevice(d) AND HostSystem(h)
Physical storage device != logical storage volume.
An NVMe interface/protocol is not equivalent to NAND flash media.

7. STORAGE OPERATIONS
operation READ(target, offset, length) -> Data | Error
operation WRITE(target, offset, payload) -> Success | Error
operation ERASE(target, range) -> Success | Error
operation FLUSH(target) -> Success | Error
operation VERIFY(target, expected_digest) -> Verified | Mismatch | Error
operation SNAPSHOT(volume) -> SnapshotReference | Error
operation REPLICATE(source, destination) -> ReplicationResult
Preconditions: authorised_access AND valid_target AND valid_range.
Postconditions must be confirmed from operation results, not presumed.

8. EXECUTION FLOW
flow StorageAccess(request):
  input: request{actor, operation, target, range?, payload?}
  resolve target -> StorageDevice|StorageVolume
  validate types and range
  enforce access control and storage policy
  check connection, device state and free capacity where relevant
  execute operation through controller/interface
  collect outcome, latency and integrity signals
  return {status, result?, metrics?, error?, provenance}
  on failure: preserve diagnostic context and avoid asserting success

9. PERFORMANCE ALGEBRA
Throughput = transferred_bytes / elapsed_seconds, where elapsed_seconds > 0
IOPS = completed_IO_operations / elapsed_seconds, where elapsed_seconds > 0
AverageLatency = sum(operation_latency) / completed_operations, where completed_operations > 0
Utilisation = occupied_bytes / usable_capacity_bytes, where usable_capacity_bytes > 0
ReportedCapacity may differ from usable capacity because of formatting, redundancy and reserved space.
Performance observations must include workload, access pattern and measurement conditions.

10. INTEGRITY AND RELIABILITY
IntegrityCheck(data) := Compare(Hash(read(data)), expected_hash)
Redundancy != Backup; replication may propagate deletion or corruption.
A successful write acknowledgement does not by itself prove long-term persistence.
StorageFailure may include media error, controller error, interface error, corruption, wear-out or environmental damage.

11. INFERENCE RULES
IF medium_type(d)=NANDFlash THEN classify(d, SolidStateStorage) [subject to supporting evidence].
IF device_type(d)=HDD THEN classify(d, MagneticRotatingStorage).
IF free_capacity(d) < requested_write_size THEN infer(PotentialCapacityFailure).
IF verified_hash != expected_hash THEN infer(DataIntegrityMismatch).
IF repeated_uncorrectable_errors(d) THEN infer(IncreasedFailureRisk), not CertainFailure.
IF BACKED_UP_TO(a,b) AND independent_copy_verified(b) THEN infer(VerifiedBackupCopy(a,b)).

12. SEMANTIC EQUIVALENCE
SEMANTIC_EQUIVALENCE("solid-state drive", "SSD", context=storage_device)
SEMANTIC_EQUIVALENCE("hard disk drive", "HDD", context=storage_device)
SEMANTIC_EQUIVALENCE("network-attached storage", "NAS", context=storage_system)
Do not equate SSD with NVMe SSD or storage with RAM without context.

13. CONFIDENCE
CONFIDENCE(assertion) in [0,1]
confidence derived from evidence quality, freshness, corroboration and source reliability.
Classifications based on verified manufacturer specifications may be stronger than inferred labels.
Missing evidence => UNKNOWN, not FALSE.

14. PROVENANCE
Record source_url, observed_at, extracted_attribute, evidence_method, model_version and confidence for each externally sourced assertion.
Distinguish specification, observed measurement and model inference.

15. FLOW_HASH
FLOW_HASH := SHA256(canonicalise({ontology_id, version, entity_types, relationships, constraints, rules, flows}))
Canonicalisation requires stable ordering, explicit type representation and normalised text encoding.
The hash is a specification for implementation; no digest is claimed here.

16. UPDATE_MODEL
UPDATE_MODEL(change):
  validate schema and type constraints
  compare incoming evidence with existing assertions
  preserve prior versions and provenance
  resolve conflicts or mark unresolved
  recompute affected inferences and FLOW_HASH
  publish versioned changes only after validation

17. AI_CONSUMPTION
AI_CONSUMPTION:
  format: typed semantic graph + executable flow specification
  required: explicit types, provenance, uncertainty, version and validation
  safeguards: do not invent capacities, specifications, reliability claims or measurements
  output: {entities, relationships, constraints, inferences, confidence, provenance, flow_hash}

18. VALIDATION TESTS
TEST invalid negative capacity -> reject
TEST logical volume treated as physical device -> type error
TEST read outside permitted range -> reject
TEST checksum mismatch -> integrity failure
TEST unknown endurance -> UNKNOWN
TEST replicated but unverified copy -> not VerifiedBackupCopy
TEST conflicting manufacturer specs -> preserve conflict for review

END FLOW ALGEBRA