CaltechExperimentalGravity / CaltechExperimentalGravity/system_ident

Stage G: EXIT GATE — full-stack CDSBackend run through TwinTransport against x1hsts

Open
#21 0 comments 0 reactions 0 assignees View on GitHub
enhancement
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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.