Intent-Driven Storage Systems
- Intent-Driven Storage Systems (IDSS) are a storage paradigm that uses high-level, declarative intent—often inferred by LLMs—to dynamically align storage behavior with application needs.
- IDSS implements a closed-loop architecture that integrates data acquisition, semantic reasoning, and policy-controlled reconfiguration to optimize aspects like caching and IOPS.
- Early systems such as RodentStore and hStorage-DB demonstrated key mechanisms that evolved into IDSS, addressing challenges like intent blindness and fragmented optimization.
Intent-Driven Storage Systems (IDSS) designate a storage paradigm in which high-level goals, requirements, and contextual signals govern storage behavior more directly than manual low-level tuning. In the storage-specific formulation, IDSS embeds LLMs into the storage control loop to infer workload and system intent from unstructured signals and to guide adaptive, cross-layer, and cross-component parameter reconfiguration (Bergman et al., 29 Sep 2025). In the broader intent-based systems literature, intent represents the functional and operational requirements of the system from the user; this includes functional intent, operational intent, and refinement intent for evolution over time (Anand et al., 9 Feb 2025). Earlier storage work already exposed closely related mechanisms through declarative layout specification, semantic information passed from DBMSs to storage managers, and on-demand data delivery, while recent work adds LLM reasoning, policy guardrails, and stronger auditability.
1. Intent as a storage abstraction
Within intent-based system design, intent is defined as the “(potentially changing) functional and operational requirements of the system from the user.” Functional intent describes features, behaviors, security, and design needs, whereas operational intent captures running parameters, SLOs and SLAs, latency, reliability, and performance requirements. Refinement intent denotes the delta between previous and new intents and is used for continuous system improvement and adaptation (Anand et al., 9 Feb 2025).
Applied to storage, this abstraction shifts emphasis from imperative specification of device-level parameters to declarative specification of desired properties. The storage-oriented interpretation in the literature explicitly includes desired functional attributes such as data durability and access latency, as well as operational goals such as resilience to node failure and compliance (Anand et al., 9 Feb 2025). The 2025 IDSS vision sharpens this point by identifying a central pathology of existing storage systems: “intent blindness,” meaning lack of visibility into workload intent and an inability to adapt to the semantics of modern, large-scale data-intensive applications (Bergman et al., 29 Sep 2025).
A key consequence is that IDSS is not limited to one representation of intent. In some systems, intent is a declarative storage layout expression; in others, it is semantic information extracted from query plans, or a workflow request describing what data should be delivered, when, and in what format. Recent LLM-mediated formulations extend this further by inferring intent from workload names, telemetry, traces, and natural language descriptions rather than requiring fully structured declarations (Bergman et al., 29 Sep 2025).
2. Control loops, lifecycle, and architectural organization
The architectural core of intent-based design is a closed loop linking specification, implementation, runtime awareness, and adaptation. One formulation identifies four major components: distributed system design, real-time context awareness, system operation, and system improvement. In this view, high-level intent is converted into architecture and code, runtime data from logs, metrics, and traces are unified with domain knowledge, operational intent is translated into an “ops model,” and detected violations generate refinement intent that can trigger reconfiguration or redesign (Anand et al., 9 Feb 2025).
A closely related taxonomy for intent-driven service management organizes the lifecycle into four intent management activities: intent specification and translation, autonomous deployment and orchestration, monitoring and awareness, and dynamic optimization and remediation. This literature emphasizes declarative input, hierarchical decomposition, closed control-loop operations, KPI-driven monitoring, and both reactive and proactive remediation for SLA fulfillment (Sharma et al., 2022). For storage, this suggests a lifecycle in which durability, latency, cost, geo-redundancy, compliance, or security constraints are expressed as intents, decomposed into domain-specific policies, monitored continuously, and revised when violations or changing workloads are observed (Sharma et al., 2022).
The explicit storage-agent architecture proposed for IDSS instantiates this loop in four phases: a Data Acquisition Agent, Data Organization, LLM-based Reasoning, and Configuration & Execution. The Data Acquisition Agent gathers telemetry and workload context; Data Organization structures raw data and links client, workload, and system state; the LLM reasons over objectives and constraints, possibly consulting a Storage Knowledge Repository via retrieval-augmented generation; and the Configuration Agent translates proposals into platform-specific actions, executes them, validates them, and can roll them back if necessary (Bergman et al., 29 Sep 2025). The same work frames these stages through four design principles: autonomous, context-aware adaptation; holistic, system-wide optimization; guarded autonomy through structured control flow; and vendor-neutral policy abstraction (Bergman et al., 29 Sep 2025).
This convergence across papers indicates that IDSS is best understood as a control architecture rather than a single implementation technique. Declarative intent, context acquisition, policy translation, enforcement, and feedback are the recurring invariants.
3. Storage precursors and concrete mechanisms
Long before the explicit IDSS label appeared, several storage systems implemented mechanisms that fit an intent-driven interpretation.
RodentStore introduced an adaptive, declarative storage system in which administrators or design tools specify the physical representation of data using a declarative storage algebra. The algebra supports grouping into rows, columns, and arrays; ordering on disk; and transforms such as project, append, select, partition, fold, prejoin, zorder, grid, and transpose. Its geospatial case study showed that different storage layouts for dense sensor data could be expressed compactly, and the reported outcome was up to 100x speedup for geospatial queries (0909.1779).
hStorage-DB addressed the “semantic gap” between DBMSs and heterogeneous storage hardware by identifying semantic information critical for storage I/O and passing it to the storage manager. Requests are classified into sequential requests, random requests, temporary data requests, and update requests; each class is assigned a QoS policy so that every request is served with a suitable storage device. The policy model is expressed as a caching priority , and the system uses explicit rules such as non-caching for sequential requests, highest cache priority for temporary data, and write-buffer priority for update requests. On TPC-H throughput tests, hStorage-DB delivered a 3.3× speedup versus HDD-only and 1.5× versus LRU, while temporary-data-intensive queries achieved 100% hit ratio for temporary reads (Luo et al., 2012).
The Intelligent Data Delivery Service (iDDS) shifted attention from persistent layout to delivery semantics. Its design decouples the “cold format” from the processing format, supports transformation on demand, and delivers event- or file-level data asynchronously and just-in-time. The architecture includes a requestor, iDDS head, DDM, Transformer, Transporter, Conductor, and workflow consumer, and its purpose is to fetch, transform, deliver, and delete data according to workflow needs rather than static replication plans (Guan et al., 2020).
These systems differ in substrate and scope, but they share a common pattern: application- or workflow-level semantics are translated into storage behavior. That pattern anticipated the later claim that storage systems should bridge “the gap between application goals and low-level system control” (Bergman et al., 29 Sep 2025).
| System | Core mechanism | Relevance to IDSS |
|---|---|---|
| RodentStore | Declarative storage algebra | High-level physical representation |
| hStorage-DB | Semantic info to QoS policy | Request intent guides device selection |
| iDDS | On-demand transformation and delivery | Workflow intent shapes data movement |
| IDSS | LLM-driven control loop | Cross-layer adaptive reconfiguration |
4. LLM-mediated IDSS and cross-layer optimization
The 2025 storage-specific IDSS proposal makes LLMs the semantic reasoning substrate of the storage control loop. Its motivation is the combination of workload heterogeneity, fragmented optimization across components, and an enormous configuration space; the paper cites systems such as Ext4 as having parameter spaces on the order of combinations (Bergman et al., 29 Sep 2025).
In this formulation, LLMs infer intent from workload names, natural language descriptions, telemetry, and I/O traces, then synthesize actionable configurations for storage components such as caching and prefetching. The same system argues that LLMs are useful because they provide semantic bridging, goal-oriented reasoning, automation, and knowledge synthesis across public and private documentation. The proposed workflow is deliberately structured rather than free-form: modular stages, clarification prompts for ambiguity, deterministic guardrail checks, fallback and rollback mechanisms, validation against documentation through retrieval-augmented generation, and an Experience DB that records configurations and operational history (Bergman et al., 29 Sep 2025).
The reported results are notable but deliberately constrained. Across synthetic and real-world traces from Alibaba and Tencent, the LLM’s chosen cache replacement policy achieved more than 97% of best-possible cache hit rates. On FileBench macro-benchmarks using VideoServer, WebServer, and VarMail, IDSS achieved IOPS improvements of up to 2.45× over baseline configurations. The paper further reports that workload-specific variants outperform non-semantically guided optimizers, particularly when workload context is available (Bergman et al., 29 Sep 2025).
This work does not present LLMs as a replacement for storage mechanisms. Rather, it places them above those mechanisms as high-level semantic optimizers, with structured workflows and policy guardrails constraining what actions can be proposed and executed.
5. Governance, auditability, and secure mediation
A recurrent issue in autonomous storage control is whether intent should merely guide optimization or also mediate effects. The intent-driven computing model offers a stronger answer: programs do not directly execute effects but instead produce finite intent values describing proposed actions. A governed runtime evaluates each intent against a decidable policy language, records the decision in a tamper-evident ledger, and only then realizes the effect. The formal interface is given by
The model proves mediation soundness, ledger completeness, non-bypass, and policy decidability, and the implementation is backed by 454 theorems in Rocq across 36 modules with zero admitted lemmas, plus property-based testing over 70,000+ random inputs with zero disagreements (McCann, 21 May 2026).
For storage-oriented systems, a plausible implication is that data-altering and data-reading operations could be reified as explicit intents and placed under the same mediation path. That would convert governance from post hoc logging into structural control, yielding event sourcing by construction, governance simulation via intent replay, and audit completeness (McCann, 21 May 2026).
Adjacent networking work shows a different realization of this principle through immutable state storage. The IS2N architecture adds a blockchain-backed middle layer to an intent-driven security software-defined network, storing intent, policy, and network-level snapshots such as device registration and OpenFlow messages. It uses FISCO-BCOS with PBFT and RPBFT, implements a four-layer architecture, and reports interaction times in the millisecond range with minimal performance degradation. It also demonstrates that snapshots can be traced and recovered using hash lookups for forensic investigation and rollback (Song et al., 2023).
Taken together, these strands indicate that intent in IDSS can serve not only optimization but also governance. The literature therefore spans a continuum from semantic tuning to policy-mediated execution.
6. Misconceptions, terminological ambiguity, and open problems
A common misconception is that IDSS is synonymous with LLM-based autotuning. The literature does not support that restriction. RodentStore expresses storage intent through declarative storage algebra; hStorage-DB uses semantic information and QoS mapping; iDDS uses on-demand transformation and delivery; and only recent work centers LLMs as reasoning engines (0909.1779). Another misconception is that intent-driven operation implies unconstrained autonomy. The storage and systems papers repeatedly emphasize human-in-the-loop validation, deterministic safety checks, clarification prompts, fallback and rollback, policy languages, and other guardrails (Anand et al., 9 Feb 2025).
The term “IDSS” is also overloaded. In addition to “Intent-Driven Storage Systems” (Bergman et al., 29 Sep 2025), the acronym names an “Interactive Decision Support System” for entropy-guided recommendation under ambiguous user intent (Tran et al., 12 Mar 2026) and the “InnoCyPES Data Storage Service,” a peer-to-peer relational data storage service built on SQLite and the D1HT one-hop DHT (Cafaro et al., 19 Jul 2025). This ambiguity matters in the literature because only the first denotes the storage paradigm centered on workload intent and high-level semantic adaptation.
Open problems are explicit across the sources. The intent-based systems vision identifies intent formalization, LLM reliability, context extraction, explainability and control, and dynamic reconfiguration without endangering consistency or availability as challenges for storage scenarios (Anand et al., 9 Feb 2025). The storage-specific IDSS proposal adds fragmented optimization, vendor lock-in, and unsafe autonomy, and answers them only partially through vendor-neutral natural-language abstractions, retrieval-augmented generation, and guarded control flow (Bergman et al., 29 Sep 2025). The SLA-management literature further stresses the need for standard intent specification languages and templates, multi-domain orchestration, interoperability with legacy systems, and efficient decomposition and allocation algorithms for non-functional requirements (Sharma et al., 2022).
The present state of the field therefore supports a precise characterization. IDSS is not a single system and not merely an acronym; it is an emerging systems paradigm in which storage behavior is driven by high-level intent, translated through closed-loop architectures into layout, placement, delivery, caching, prefetching, and remediation decisions. Earlier systems demonstrated its constituent mechanisms; newer work seeks to unify them with LLM-based reasoning, formal mediation, and policy-governed autonomy.
