CaltechExperimentalGravity / CaltechExperimentalGravity/system_ident
Stage G: EXIT GATE — full-stack CDSBackend run through TwinTransport against x1hsts
- Dominant language
- Python
- Stars
- 0
- Forks
- 1
- PR merge metrics
- No merged PRs in 30d
Description
**Stage G (spec §6).** The Component 1 exit gate. Everything else in the campaign is
upstream of this.
### The gate
```
system_ident run src/system_ident/configs/cds_twin_transport.yml --cds --no-dashboard
```
against the **existing compiled `x1hsts` model**, with recovery scored against the rtsfreerun oracle
**within the CRB** — the same criterion Stage 1 used ([`tests/test_sos_sysid.py`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/tests/test_sos_sysid.py), worst 1.64σ).
Codified as `tests/test_cds_twin_transport.py`, `skipif` the model is absent, following
[`tests/test_rtsfreerun_backend.py:192`](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/tests/test_rtsfreerun_backend.py#L192).
### Why `x1hsts` and not an SOS composite
The roadmap's ladder puts this after Stage 2 — authoring `gen_x1sos6dof.py`, the rtsfree SOS composite —
which is **not written** and lives in the separate `digital_twin` repo. But **the transport is
plant-agnostic**: it validates GPS-scheduled injection, the ramp construction, period-preserving
resampling, the read cache, the lifecycle and the safety gate, none of which care what plant is on the
other end. An HSTS validates it exactly as well as an SOS would, and decouples this campaign from work in
another repo on another machine. The SOS composite remains valuable — for the *physics* gate, not this one.
### Companion test files
- `tests/test_cds_backend.py` — on the Stage A harness: FRF invariant under GPS offsets 1 / 37 / 511
(reproducing 7.4e-12) **and** a stashed-X variant that must fail; untapered integer-period tiling with
`ramptime == ramp_s`; watchdog channel-map wiring; integer-rate, short-read and missing-channel
assertions; read-cache correctness across generations.
- `tests/test_cds_safety.py` — the approval-gate and amplitude-limit assertions.
- `tests/test_cds_lazy_import.py` — `import system_ident` must not import `awg`/`cdsutils`.
- A `skipif find_spec("awg") is None` **read-only** real-transport smoke test: probe the rate, `getdata` a
quiet segment, **no injection**. Safe to run on the deployment machine without operator approval —
and it is the only part of the campaign that touches the real CDS libraries.
---
**Campaign:** CDS hardware backend · branch [`feat/cds-hardware-backend`](https://github.com/CaltechExperimentalGravity/system_ident/tree/feat/cds-hardware-backend)
· [spec](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/specs/2026-08-03-cds-hardware-backend-design.md) · [plan](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/docs/superpowers/plans/2026-08-03-cds-hardware-backend.md) · [handoff](https://github.com/CaltechExperimentalGravity/system_ident/blob/feat/cds-hardware-backend/notes/cds-hardware-bringup-2026-08.md)
*Code is deferred until the plan and issues have been reviewed.*
Contributor guide
No contributing guide indexed for this repository
Research direction
Read the linked CDS hardware backend spec and plan first, then inspect tests/test_sos_sysid.py and tests/test_rtsfreerun_backend.py:192. Run the stated system_ident command against the existing compiled x1hsts model when available, and use the companion CDS tests to verify the exit gate, including recovery within the CRB and the documented safety and lifecycle checks.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- python
- Domain
- backend, testing
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100