Summary
Implement the layered QEC abstraction model proposed in #508, with explicit artifacts and lowering/verification boundaries from abstract codes through protocols and physical implementations to target-native timed execution.
This is an umbrella tracking issue. Individual architectural decisions should be discussed in #508, while implementable pieces are tracked as focused child issues.
Desired outcome
PECOS should support a coherent flow resembling:
AbstractCode
-> EncodedProgram / logical operations
-> QecProtocol
-> ImplementationPlan / SyndromeExtractionPlan
-> MappedCircuit
-> DeviceSchedule
-> Executable / run configuration
The exact names and number of persistent IRs remain subject to the RFC. The implementation should avoid one monolithic object with many optional fields.
Cross-cutting requirements
- Explicit provenance between source and lowered artifacts.
- Validation or verification contracts at each boundary.
- Support for multiple implementations of the same abstract interface.
- Clear attachment points for noise models and experiment models.
- Support for both static circuits and adaptive hybrid protocols.
- Consistent Rust and Python APIs where appropriate.
- Offline, deterministic tests for all external catalog integrations.
Initial workstreams
Child issues:
Completion criteria
- The RFC reaches an accepted initial architecture.
- Each agreed abstraction has an owner/module and documented responsibilities.
- At least one end-to-end vertical slice lowers from an abstract code through a QEC implementation into the existing PECOS execution/simulation stack.
- Verification/provenance information is retained across the slice.
- User-facing documentation explains where code-capacity, phenomenological, circuit-level, and device-level experiments attach.
References
Summary
Implement the layered QEC abstraction model proposed in #508, with explicit artifacts and lowering/verification boundaries from abstract codes through protocols and physical implementations to target-native timed execution.
This is an umbrella tracking issue. Individual architectural decisions should be discussed in #508, while implementable pieces are tracked as focused child issues.
Desired outcome
PECOS should support a coherent flow resembling:
The exact names and number of persistent IRs remain subject to the RFC. The implementation should avoid one monolithic object with many optional fields.
Cross-cutting requirements
Initial workstreams
Child issues:
Completion criteria
References
crates/pecos-qec/docs/levels-of-abstraction.md