跳转至

10 RunResult / ValidationReport

Purpose

This chapter defines the standard result and validation reporting structures.

ValidationReport

ValidationReport is the canonical validation abstraction. It should provide:

  • an overall success or failure state
  • structured messages with severity
  • stable message codes
  • optional path information identifying where the issue applies

Validation should cover both structural validity and execution-relevant semantic constraints.

Validation may be applied at several stages, including:

  • bundle and schema conformance checks
  • canonical program checks
  • capability-envelope checks against DeviceSpec
  • calibration availability checks against CalSet
  • profile-compatibility checks for compatibility export

The top-level report should remain stable even when the underlying validator is backend-specific or profile-specific.

RunResult

RunResult is the canonical execution-result abstraction. It should provide:

  • backend identifier
  • program identifier
  • execution status
  • measurements or classified outputs
  • diagnostics
  • extensible metadata

In practical repository use, the result envelope may also carry execution metadata such as bundle identity, profile, shot count, timing summary, or references to external traces.

Standardization Rule

Result and validation abstractions must remain backend-independent at the top level even when backend-specific metadata is carried alongside them.

This separation is important because repository interoperability depends on common envelopes even when payload details vary widely across hardware families.

Extension Rule

Future backends may add richer result payloads such as raw IQ, photon counts, site occupancy traces, analog traces, or vendor-native diagnostics. Such extensions should remain additive rather than replacing the standard result envelope.

Relationship to Compatibility Profiles

Result and validation reporting may depend on the selected compatibility profile, but they should not be defined by that profile alone. For example:

  • an OQ-0 export may still yield a standard RunResult
  • an OQ-X export may carry richer diagnostics or extension metadata
  • validation may fail because a requested profile is incompatible with the canonical program or available sidecars

The profile influences reporting context, not the existence of the canonical reporting envelope.

Publication-Oriented Rule

This chapter defines the stable reporting abstractions. Detailed example payloads, backend-specific trace formats, and future diagnostic artifacts should be linked from examples or developer documentation rather than overloading the normative chapter text.