Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#21 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
35/100
Issue type
Feature
Clarity
Mostly clear
Activity status
Quiet
Tech stack
python
Domain
backend, testing

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.

Description

enhancement

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, worst 1.64σ).
Codified as tests/test_cds_twin_transport.py, skipif the model is absent, following
tests/test_rtsfreerun_backend.py:192.

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
· spec · plan · handoff
Code is deferred until the plan and issues have been reviewed.

Dominant language
Python
Stars
0
Forks
1
No merged PRs in 30d

Getting set up

This project ships no dev container, Dockerfile or contributing guide, so setting up is up to you: start from its README, and see our first-contribution guide for the general steps.

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from CaltechExperimentalGravity/system_ident

All issues in CaltechExperimentalGravity/system_ident

Similar issues

More Python issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.