PaperlayerView exact revision on arXiv

Source-linked AI summary

DeepUnfolding_Agent: A Classical_Quantum Adaptive Control API

Shanika Iroshi Nanayakkara, Shiva Raj Pokhrel

arXiv:2610.20615v1cs.CLcs.LG

TL;DR

Adaptive controllers are often coupled to task-specific scripts, making them difficult to reuse, compare, audit, or deploy across optimization workflows. DeepUnfolding-Agent provides a schema-driven FastAPI control service that separates controller logic from external execution. Layered software tests demonstrate its use as a reusable adaptive-control service across classical, quantum, hybrid, and external workflows.

  • Problem

    Adaptive controllers embedded in task-specific scripts are difficult to reuse, compare, audit, or deploy across external workflows.

    Source: §1 · p. 1

  • Method

    DeepUnfolding-Agent exposes deep-unfolded adaptive control through a schema-driven FastAPI service that separates controller intelligence from external execution.

    Source: §1 · p. 2

  • Results

    Layered software tests demonstrate DeepUnfolding-Agent as a reusable adaptive-control service for classical, quantum, hybrid, and external-domain workflows.

    Source: §1 · p. 2

  • Takeaways & Limitations

    A strategy-agnostic schema contract supports a shared controller lifecycle across classical, quantum, hybrid, and external optimization workflows.

    Source: §1 · p. 2

    Optional real-QPU validation is a hardware smoke test dependent on user credentials, network availability, queue status, and backend availability.

    Source: §6.4 · p. 11

Abstract

from arXiv · show

Adaptive optimization workflows in machine learning, federated learning, quantum machine learning, and hybrid classical quantum systems often embed controller logic directly inside task specific training scripts. This coupling limits reuse, reproducibility, safety validation, and fair comparison across execution environments. This paper presents DeepUnfolding Agent, a schema-driven FastAPI platform that exposes deep unfolded adaptive control as an external software service. External executors register a strategy schema, submit round-level diagnostic variables, receive schema-bounded control actions, execute one optimization round, and return feedback for controller update. The framework separates controller intelligence from domain specific execution through a strategy registry, diagnostic to state adapter, controller factory, safety guard, executor abstraction, feedback update path, SQLite persistence layer, Docker deployment, and reproducible benchmark scripts. The implementation supports classical, quantum-aware, hybrid, Qiskit Aer, and optional IBM quantum processing execution pathways. We validate the software through unit, schema, API, safety, orchestration, Quantum execution, checkpointing, and Docker tests, and demonstrate external user fixed versus adaptive workflows across finance, healthcare, genomics, transport, noisy quantum simulation, and hardware backed IBM Quantum execution. The results show that DeepUnfolding-Agent provides a reusable and traceable adaptive control layer for heterogeneous optimization workflows. Our quantum experiments are interpreted as API level quantum control and hardware portability evidence.

1. Introduction

DeepUnfolding-Agent addresses the difficulty of reusing adaptive controllers embedded in task-specific workflows by separating controller logic from external execution. Its schema-driven FastAPI service supports bounded control, feedback updates, and layered software validation across classical, quantum, hybrid, and external workflows.

1. Introduction

  • Task-specific adaptive controllers are difficult to reuse, compare, audit, or deploy across workflows, limiting reproducibility and practical value.Runtime controls must adapt to diagnostics such as loss, gradient norm, data heterogeneity, shot noise, resource use, and convergence behavior.Source: §1 · p. 1
  • A reusable, strategy-agnostic interface is needed because deep-unfolded controllers often remain embedded in specific algorithms or experimental scripts.Such embedding limits reuse and makes comparisons across classical ML, federated learning, quantum, hybrid, and external workflows require repeated re-implementation.Source: §1 · p. 1
  • Strategy schemas define diagnostic variables, controllable variables, types, and bounds, supporting a unified controller lifecycle for classical, quantum, hybrid, and external strategies.The service supports registration, schema adaptation, controller creation, bounded suggestions, execution routing, feedback collection, updates, and logging.Source: §1 · p. 2
  • DeepUnfolding-Agent separates deep-unfolded controller intelligence from external execution through a modular FastAPI service for classical, quantum, and hybrid workflows.The platform exposes public REST endpoints for strategy management, controller operations, quantum-controlled execution, experiment execution, and retrieval.Source: §1 · pp. 1–2
  • Layered tests demonstrate DeepUnfolding-Agent as a reusable adaptive-control service for classical, quantum, hybrid, and external-domain workflows.Validation includes unit, schema, API, safety, orchestration, quantum execution, external executor, and Docker tests.Source: §1 · p. 2

2. Related Work and Gap

Related tools address trial-level configuration search, embedded deep-unfolding methods, or execution infrastructure. DeepUnfolding-Agent instead emphasizes a reusable schema-driven controller lifecycle across classical, quantum, hybrid, and external optimization workflows.

2. Related Work and Gap

  • The related work spans hyperparameter optimization and AutoML, deep unfolding, federated-learning and quantum software frameworks, and MLOps and workflow orchestration.Table 3 summarizes distinctions between these categories and the proposed API-level adaptive-control framework.Source: §2 · p. 2
  • Hyperparameter optimization tools search trial-level configurations, while federated-learning and quantum frameworks provide execution infrastructure rather than a bounded adaptive-control layer.Deep-unfolding methods also commonly remain embedded in specific models or algorithms.Source: §2 · p. 2
  • DeepUnfolding-Agent’s distinction is its reusable schema-driven controller lifecycle for classical, quantum, hybrid, and external optimization workflows.Its novelty is not only the FastAPI implementation.Source: §2 · p. 3

3. Design Requirements and Problem Formulation

DeepUnfolding-Agent addresses the difficulty of reusing adaptive control across workflows by separating controller logic from domain-specific execution. Its schema-driven API supports bounded, feedback-updated control across classical, quantum, and hybrid optimization.

3. Design Requirements and Problem Formulation

  • The framework decouples adaptive-control logic from task-specific execution so the same API service can be reused across diverse optimization workflows.External executors send diagnostics, apply bounded controls, and return feedback for controller updates.Source: §3 · p. 3

3.1. Design Requirements

  • A stable public API and strategy schemas specify observed diagnostics and bounded controls, while leaving optimizer, aggregation, simulator, and backend details to the executor.The interface supports built-in and user-defined workflows.Source: §3.1 · p. 3
  • Schema or user-defined bounds constrain returned controls, with support for classical variables such as learning rate and quantum variables such as shot count and circuit depth.The requirements also call for feedback-driven updates using metrics returned after each round.Source: §3.1 · p. 3
  • The API is intended to support reproducibility and traceability, while command-line workflows and autogenerated documentation serve non-developers and plugins support advanced users.New strategy schemas and executor plugins can be added without changing the internal API.Source: §3.1 · p. 3

3.2. Problem Formulation and Formal Control Contract

  • A strategy schema defines ordered diagnostic and control sets, admissible bounds, and data-type constraints; the adapter validates required numeric diagnostics before invoking the controller.The formalization also describes the external workflow objective and bounded control domain.Source: §3.2 · pp. 3–4
  • The API-level contract maps diagnostics to a schema-ordered state, generates raw controls, enforces bounds and types, and returns executor feedback for controller updates.The same formulation applies to classical, quantum, hybrid, and user-defined workflows.Source: §3.2 · p. 4

3.3. Classical and Quantum Instantiations

  • Classical federated-learning examples use loss, gradient norm, update norm, data heterogeneity, and round index to inform bounded optimizer and training controls.The executor applies these controls within a selected aggregation strategy and optimizer; the API does not implement either internally.Source: §3.3 · pp. 4–5
  • Quantum workflows use controls such as shot count and circuit depth with quantum diagnostics, while external executors handle QFL simulation, Qiskit Aer, noisy tests, or IBM QPU execution.Backend-specific circuit construction, simulation, transpilation, runtime execution, and job submission remain within the executor.Source: §3.3 · p. 5

4. DeepUnfolding-Agent Architecture

DeepUnfolding-Agent separates adaptive controller logic from domain-specific execution through a schema-driven service. Its architecture maps named diagnostics to controller inputs, bounds suggested controls, and supports external execution and feedback across workflow types.

4. DeepUnfolding-Agent Architecture

  • The schema-driven control loop registers a strategy, builds ordered state from runtime diagnostics, projects controller outputs into safety bounds, executes a round externally, updates from feedback, and persists the run.The architecture supports reuse across classical, quantum, hybrid, and user-defined optimization workflows.Source: §4 · p. 5

4.1. Strategy Schema

  • Strategy schemas specify ordered diagnostics and controls, admissible bounds, and data types, keeping the API independent of any particular optimizer, circuit, simulator, or dataset.Built-in and user-defined workflows can reuse the schema interface without changes to the public API or controller backend.Source: §4.1 · pp. 5–6

4.2. Diagnostic Adapter

  • The diagnostic adapter maps named external observations into the selected schema’s ordered numerical state vector for the controller.The same bridge supports classical, quantum, hybrid, and user-defined workflows.Source: §4.2 · p. 6

4.2.1. Validation and Error-Handling Policy

  • Missing or non-numeric required diagnostics are rejected before controller inference, and the API does not implicitly impute missing values.The adapter requires submitted diagnostics to comply with the registered schema; diagnostic values are not typically clipped to bounds.Source: §4.2.1 · pp. 6–7

4.3. Deep-Unfolded Controller Backend

  • A controller is created from the selected strategy schema and exposed through a reusable controller identifier rather than direct instantiation of internal Python classes.The identifier supports subsequent suggestions, execution, updates, saving, and loading.Source: §4.3 · p. 7

4.4. Safety-Bounded Projection

  • The safety-bounded projection layer converts and validates raw suggestions, clipping controls to the admissible ranges set by the schema and user constraints.This ensures the executor receives bounded, valid controls for its workflow.Source: §4.4 · p. 7

4.4.1. Safety-Bounded Control Suggestion

  • The suggestion path converts diagnostics into schema-ordered state, obtains raw controller outputs, and projects them into the schema-defined feasible set before returning them.Continuous controls are clipped to bounds and integer-valued controls converted to valid integers.Source: §4.4.1 · p. 8

4.4.2. Control Defaults and Bound Enforcement

  • External-user runners apply fallback defaults only when a control key is missing, then clip those defaults to configured bounds before execution.These executor-side defaults complement, rather than replace, API-side schema validation.Source: §4.4.2 · p. 8

4.5. External Executor Protocol

External executors apply the API’s bounded controls within their own workflows and return round-level outputs. Those outputs can become a multi-objective feedback signal for controller updates.

4.5. External Executor Protocol

  • The API supplies bounded controls to external executors, which retain ownership of datasets, training loops, optimizers, circuits, simulators, and QPU job submission.The same diagnostic-control-feedback interface is used across classical and quantum execution pathways.Source: §4.5 · p. 8

4.6. Feedback Update, Persistence, and Reproducibility

  • Round-level execution outputs are mapped to scalar and optionally structured feedback for controller updates, rather than relying solely on final task accuracy.Feedback may reflect validation quality, optimization stability, resource use, and execution cost.Source: §4.6 · pp. 8–9
  • The feedback objective weights prediction quality, optimization stability, resource efficiency, and execution cost; resource and latency terms can be supplied by external executors without changing the API contract.The weights are nonnegative, and the feedback metrics logged depend on the selected workflow.Source: §4.6 · pp. 8–9

5. API Lifecycle and External-Executor Contract

The public API exposes a reusable diagnostic-control-feedback lifecycle while leaving domain-specific execution outside the controller service.

5. API Lifecycle and External-Executor Contract

  • Executors select a strategy, create a controller, submit schema-compatible diagnostics for bounded controls, run an optimization round, and return feedback for updates and persistent logging.The same lifecycle applies to classical, quantum-aware, hybrid, and user-defined workflows.Source: §5 · p. 9
  • The API validates schema-bearing requests and bounds controls before execution, preserving traceable records of diagnostics, controls, feedback, metrics, and artifacts.Supplementary Section S4 provides detailed schemas, endpoint errors, protocol tables, pseudocode, and failure-handling policies.Source: §5 · pp. 9–10

6. Software Validation Methodology

The software is evaluated through layered tests intended to verify components, public API interactions, closed-loop operation, reproducibility, and deployment. Quantum execution validation uses Qiskit Aer by default, with IBM QPU checks treated as optional portability smoke tests.

6. Software Validation Methodology

  • Validation spans unit, integration, system, artifact, and deployment layers to test component correctness, API interactions, repeated control, recoverable outputs, and operation beyond development.The stated objective is reliable creation, querying, updating, bounding, persistence, and reuse by external executors.Source: §6 · p. 10

6.1. Unit Validation

  • Unit tests cover schemas, diagnostic conversion, controller output types, safety bounds, feedback updates, and checkpoint round-trips; invalid schemas and diagnostics are expected to fail before inference.Safety-bound tests check that out-of-range classical and quantum controls are adjusted while in-range values remain unchanged.Source: §6.1 · p. 10

6.2. Integration Validation

  • Integration tests exercise service availability, strategy registration, controller creation, bounded suggestions, feedback updates, quantum-round execution, and experiment retrieval through the public API.Checks include HTTP status and expected JSON fields.Source: §6.2 · p. 10

6.3. System Validation

  • System tests repeat controller creation, suggestions, external execution, feedback, and updates across rounds, while orchestration tests assess bounded runs, stopping decisions, summaries, and trace preservation.The tests check consistency of identifiers, diagnostics, controls, metrics, and update records across repeated operation.Source: §6.3 · p. 10

6.4. Quantum Execution Validation

  • Qiskit Aer tests convert quantum diagnostics to controller state, return bounded quantum controls, and feed simulated execution metrics into controller updates.Aer is the default reproducible backend because it requires neither cloud credentials nor physical hardware.Source: §6.4 · pp. 10–11
  • IBM QPU validation is an optional, credential-gated portability smoke test, not an evaluation of optimization performance, accuracy, latency, queueing, or hardware superiority.Real-QPU execution depends on credentials, network, queue, and backend availability.Source: §6.4 · p. 11, Table 8 · p. 11

6.5. Artifact and Reproducibility Validation

  • Artifact validation checks that run metrics, control histories, diagnostics, feedback, configurations, controller metadata, checkpoints, and summaries can be inspected and traced after execution.Traceability includes controller and strategy identifiers, schema, controls, feedback, and output artifacts.Source: §6.5 · p. 11

6.6. Deployment Validation

  • Deployment validation covers running the service outside the local development workflow.The supplied passage identifies Docker deployment validation but does not specify its outcomes.Source: §6.6 · p. 11, Table 9 · p. 12

7. Reproducible External Usage and Evaluation

The section shows how external users can run fixed-baseline and adaptive workflows through a reusable service interface. The executor retains responsibility for domain-specific execution while DUAgent handles bounded controls and feedback updates.

7. Reproducible External Usage and Evaluation

  • The external-user benchmarks compare manually specified fixed controls with controls returned by the deep-unfolded controller API.The workflows test whether the controller pathway executes and changes the training or execution trajectory relative to a static configuration.Source: §7 · p. 12

7.2. Artifact Reproducibility Checklist

  • The external-user artifact includes a quick-start CSV generator, public runner, strategy schemas, executor templates, and usage documentation.Its checklist distinguishes reproducing the artifact from reproducing every reported benchmark result.Source: §7.2 · pp. 12–13
  • Users can reproduce the artifact by installing the software, starting the API, running an external CSV workflow, and inspecting generated logs, summaries, configurations, and plots.The same API can be extended to user-defined classical or quantum workflows by replacing the schema and executor plugin.Source: §7.2 · p. 13

7.3. External HTTP Control Protocol

  • The HTTP protocol creates a controller, exchanges round-level diagnostics for bounded controls, then returns workflow feedback for controller updates.The external executor manages the dataset, model, training loop, simulator, or QPU backend; DUAgent manages adaptive control.Source: §7.3 · p. 13

7.4. Classical and Quantum FL External Benchmark Execution

  • Classical and QFL external workflows use the same executor pattern, applying returned controls to learning parameters or quantum variables such as shot count and circuit depth.The executor loads data, runs each workflow round, and submits validation feedback; only dataset-specific command arguments change across the cited application domains.Source: §7.4 · pp. 13–14

8. Per-Dataset External Benchmark Results

Across external benchmarks, DUAgent improves overall optimization outcomes relative to fixed controls, with stronger classical results and more mixed QFL behavior. Quantum simulator and IBM hardware pathways demonstrate API execution and portability, while noisy simulations expose conditions where the current controller is less effective.

8. Per-Dataset External Benchmark Results

  • 72.9% final Macro-F1 versus 62.6%, final validation loss 0.304 versus 0.613, and 5.00× target speed-up were reported for classical DUAgent versus the fixed baseline.Across workflows, DUAgent achieved the best overall final Macro-F1, final validation loss, loss reduction, and time-to-target speed-up; QFL final Macro-F1 remained similar to fixed and heuristic baselines.Source: Table 14 · p. 14, §8 · pp. 14–15

8.2. Quantum Error-Family Evaluation

  • DUAgent delivered optimization gains under clean, readout, and depolarising noise, but was weaker or less consistent under thermal, coherent, and mixed noise.Table 15 summarizes macro-averaged results relative to each dataset–error-family fixed-QFL baseline; the authors identify a need for more noise-aware modeling.Source: Table 15 · p. 15, §8.2 · p. 16

8.1. Quantum Qiskit Aer Usage

  • The Qiskit Aer endpoint test passed, validating public-API execution of an adaptive quantum round in the reproducible simulator pathway.The simulator route does not require cloud credentials or queue access; error bars in the aggregate analysis reflect dataset and workflow variation, not repeated random seeds.Source: §8.1 · p. 15

8.3. Real IBM QPU Execution

  • The same diagnostic–control–feedback loop ran on IBM Quantum hardware, supporting hardware portability rather than quantum-advantage or simulation-superiority claims.Backend-specific operations remain inside the executor while the API contract stays unchanged.Source: §8.3 · p. 16, Table 16 · p. 17

9. Limitations

The evaluation supports software-level validation and API reusability, but not broad performance generalization or production readiness. The authors identify limits in evaluation scale, quantum-task scope, controller guarantees, and security.

9. Limitations

  • The evaluation uses limited dataset sizes, communication rounds, seeds, and execution budgets rather than large-scale deployment.Larger studies with more seeds, longer runs, and stronger task-specific baselines are required before broad performance claims.Source: §9 · p. 17
  • The selected benchmarks demonstrate API-level reusability but do not establish domain-general superiority.The authors call for larger datasets, domain-specific models, and more comprehensive baseline comparisons.Source: §9 · p. 17
  • QFL and IBM QPU results are evidence of quantum-aware control and hardware portability, not quantum advantage.Simulator workflows use reduced features, limited circuit depths and shot budgets, and simplified variational models; hardware runs face queue, calibration, device-noise, availability, and shot-limit constraints.Source: §9 · p. 17
  • The controller provides bounded suggestions from selected diagnostics and feedback but does not guarantee globally optimal policies.Performance depends on diagnostics, control bounds, feedback objectives, configuration, safety constraints, and executor backend; component-wise ablations are needed to isolate their effects.Source: §9 · p. 17
  • DUAgent is a research-oriented API, not a complete secure production platform.Production deployment would require authentication, authorization, encrypted transport, rate limiting, secure credential management, monitoring, and additional safeguards.Source: §9 · p. 17

10. Conclusion

The conclusion presents DUAgent as a reusable adaptive-control API that separates controller intelligence from task-specific execution. Its evaluation supports a unified interface across classical and quantum-aware workflows, while future work targets larger evaluations, broader models and hardware, and production features.

10. Conclusion

  • DUAgent exposes controller creation, bounded suggestions, feedback updates, and reproducible artifact retrieval through a reusable service for classical, quantum-aware, and hybrid workflows.The same diagnostic–control–feedback interface is intended to be reused across heterogeneous optimization workflows.Source: §10 · p. 17
  • Classical and quantum-aware experiments show that the API can regulate domain-specific controls, supporting the feasibility of a unified controller-agent interface.Examples include learning rate, proximal strength, and local epochs in classical workflows, and theta learning rate, shot count, circuit depth, and measurement reuse in quantum-aware workflows.Source: §10 · p. 17
  • Future work includes larger multiseed evaluations, stronger domain-specific baselines, more expressive quantum models, broader hardware execution, and production-oriented features.Proposed features include secure authentication, multi-user tracking, persistent controller management, and integration with privacy-preserving federated workflows.Source: §10 · p. 17

Software Availability

DeepUnfolding-Agent is released as open-source research software, with public documentation and an implementation repository containing the service and reproducibility materials.

Software Availability

  • DeepUnfolding-Agent is released as an open-source research software artifact.Source: Software Availability · p. 17
  • The public project website provides documentation, overview material, and links to the implementation repository.Source: Software Availability · p. 17
  • The repository contains the FastAPI service, controller backends, strategy schemas, runners, benchmark scripts, Docker configuration, tests, and reproducibility artifacts.Source: Software Availability · p. 17

Related papers

Loading 2610.20615v1…