Parity Status
=============

The OpenRadioss corpus is tracked at fixture level. CI writes two reports:

* ``openradioss_parity_corpus_report.toml`` for machine-readable status;
* ``openradioss_parity_corpus_report.md`` for review and operator handoff.

Current Corpus Shape
--------------------

The committed corpus has five tiers:

.. list-table::
   :header-rows: 1

   * - Tier
     - Purpose
   * - ``geometry``
     - Starter model state without engine execution.
   * - ``geometry_meshing``
     - Mesh topology and neutral model parity.
   * - ``geometry_meshing_results``
     - Starter and engine outputs reduced to native results.
   * - ``geometry_meshing_results_post``
     - Native post-processing replay from results.
   * - ``verification_manual``
     - Quarantined public end-to-end examples.

Status Semantics
----------------

``blocked``
   The fixture does not yet have result artifacts to compare.

``pending``
   The fixture has native reference results, but no solver parity pass has
   been recorded in the latest dynamic scoreboard.

``pass`` / ``fail``
   The latest dynamic parity scoreboard contains a solved candidate and
   field comparison status for the fixture.

Field Policy
------------

Dynamic result reports split fields into explicit parity scopes:

``phase1_target``
   Solver/model-owned fields that count toward the first OpenRadioss parity
   gate: frame time and cycle, mesh identity, nodal ``U``/``V``/``A``,
   transient ``RF``, and ``TIME_STEP``.

``deferred``
   Fields that remain visible in the report but do not define the first
   solver parity gate yet: element recovery, plasticity, damage, contact,
   energy, and generic history channels.

The TOML report keeps both ``status`` for the full artifact and
``phase1_status`` for the current solver-owned gate. This prevents deferred
OpenRadioss/post-processing work from hiding the active solver blockers.

Reference Provenance
--------------------

Corpus reports include ``results_reference_kind`` for every fixture with
``results.npz``. The committed clean-room fixtures currently report
``synthetic_clean_room_contract`` because their deterministic references are
generated corpus contracts; real OpenRadioss replay output is built outside
the fixture tree by CI and local runner commands. This makes the scorecard
explicit about whether a failing row is comparing against a synthetic contract
or against vendor-produced solver output.

Raw Output Ingestion
--------------------

The native result path currently accepts numeric data from CSV exports,
converted VTK animation files, status listings, and directly parsed binary
T-family time-history frames. Binary A-family animation and H3D outputs are
still metadata/classification coverage unless replay produces converted
animation artifacts.

Readiness Diagnostics
---------------------

Dynamic score artifacts also record whether a generated candidate was solved
from a replayed deck that contains active loads and constraints. A readiness
status such as ``missing_active_openradioss_loads_and_constraints`` means the
reference has nonzero Phase 1 fields, but the replayed model currently gives
the solver no equivalent load or boundary condition state. Those rows point
to importer/deck-translation work before RF sign or U/V scaling can be judged.

Clean-room fixtures may carry their source load state in ``mapdl.dat`` while
the generated OpenRadioss starter deck only covers geometry and material
cards. The fixture reader applies those ``D``/``F``/``SF`` sidecar records only when
the OpenRadioss replay has no active load state, so scheduled scorecards can
separate solver-ready numeric failures from importer-readiness failures.

CI Cadence
----------

The scheduled OpenRadioss parity workflow runs on a cron cadence and can
also be started manually with ``workflow_dispatch``. It uploads corpus and
dynamic parity score artifacts so the next implementation batch can start
from concrete failing fields rather than from anecdotal status.

Dynamic parity plans can use replay-produced reference results from an
external root. When ``--reference-results-root`` is provided, each fixture row
records whether comparison used ``external_reference_root`` or fell back to the
committed ``fixture_contract``. This keeps solver-vendor parity distinct from
clean-room fixture contracts while preserving partial local runs.