跳转至

17 Roadmap

Purpose

This chapter defines the staged development direction for future versions.

Core Requirement

The roadmap should preserve architectural continuity while making room for future conformance, runtime, and backend extensions.

Roadmap Philosophy

The roadmap SHALL evolve the repository by deepening the existing architecture rather than redefining it. Future versions SHOULD expand conformance, diagnostics, backend coverage, and runtime capability while preserving the canonical role of UQCI IR and the normative status of sidecar artifacts.

v0.1

The initial public release focuses on repository-native fundamentals that already correspond to the current repository shape:

  • canonical typed models for UQCI programs and sidecar artifacts
  • bundle loading, writing, and validation helpers
  • JSON Schema files aligned with the typed models
  • OpenQASM compatibility export profiles
  • runnable superconducting and neutral-atom mock backends
  • repository-native tests, documentation, and CLI commands

This phase is intentionally narrow. Its purpose is to make the specification executable and inspectable without overclaiming production readiness.

v0.2

The next stage SHOULD improve operational depth while staying lightweight. Recommended priorities include:

  • optional ion-trap mock backend support
  • richer diagnostics and trace artifacts
  • additional bundle inspection and patching helpers
  • broader compatibility export coverage
  • backend capability inspection and reporting

These items align with the existing repository extension notes and can be delivered without changing the architectural doctrine established in earlier chapters.

v0.3 and Beyond

Longer-term work MAY include:

  • experimental adapters for real hardware environments
  • prototype scheduling and routing modules
  • richer calibration lifecycle workflows
  • conformance test suites for third-party implementations
  • optional runtime orchestration prototypes above the current repository scope

If pursued, these items should be layered on top of the existing canonical core rather than re-centering the architecture around a backend-specific or export-specific representation.

Release-Oriented Guidance

The reference Word drafts recommend publishing the specification together with machine-readable schemas, a reference implementation, and example bundles. The current repository roadmap remains compatible with that guidance:

  • Markdown chapters become the repository-native specification
  • JSON Schema files remain the machine-readable artifact layer
  • Python modules remain the reference implementation layer
  • example bundles and exports remain the runnable demonstration layer

Stability Rule

Future releases SHOULD treat the following as continuity anchors:

  • QOS as the runtime and systems viewpoint
  • UQCI as the canonical protocol layer
  • OpenQASM as the compatibility and exchange layer
  • DeviceSpec, CalSet, Manifest, and Bundle as normative sidecar artifacts

Changes that would weaken those anchors SHOULD be treated as architectural revisions rather than routine feature additions.