[deferred] Foton ZPK/SOS export + provenance manifest for a delivered fit
Nobody has claimed this yet.
Assessment
- Difficulty
- 5/5
- Estimated time
- Over a week
- Newbie friendliness
- 25/100
Research direction
Start by reading the linked design spec and plan, then inspect src/system_ident/provenance.py and tests/test_provenance.py; .github/workflows/ci.yml:26 identifies the enforced test gate. Determine the scope for Foton ZPK/SOS export and the provenance manifest from those documents. Done means the reviewed plan is implemented without expanding SOS cascades and the provenance test gate passes.
Written by the indexing model from the issue text.
Description
Component 2 — deferred.
A fit is only useful to the control room if it can be dropped into Foton and if its provenance is
auditable.
Export
Foton ZPK / SOS export of the delivered model. Two traps recorded from prior work:
- Foton's "f"-plane sign conventions differ from "s"; scientific notation needs an explicit
+. - Do not expand an SOS cascade into a high-order polynomial. The sibling project found a 32nd-order
filter's coefficients span ~40 decades, which makes the information matrix singular — refitting beats
truncating (measured 3e-4 vs 38% error). Work from the SOS.
Provenance manifest
Every real hardware number must arrive through
src/system_ident/provenance.py record(name, value, kind, source, unit=) with
kind ∈ {MEASURED, PAPER, USER, CONSTANT, DERIVED}. ASSUMED fails CI — and note that
tests/test_provenance.py is the only test CI runs (.github/workflows/ci.yml:26), so this
is the one gate that is always enforced.
That makes the manifest cheap to add and expensive to skip: counts↔N calibration, DAC limits, front-end
rate and channel names all become recorded, sourced values rather than magic numbers.
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
- PR merge metrics
- 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
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
More from CaltechExperimentalGravity/system_ident
-
Difficulty 4/5 3-5 days Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 15/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 35/100
-
enhancement
Difficulty 5/5 Over a week Newbie friendliness 25/100
All issues in CaltechExperimentalGravity/system_ident
Similar issues
-
Difficulty 2/5 1-3 hours Newbie friendliness 65/100
NVIDIA/flare-local-inference#90 ·
Maintainers usually reply within 1 day
-
area/streaming comp/gateway P2 platform/telegram type/bug
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
NousResearch/hermes-agent#144897 ·
Maintainers usually reply within 1 day
-
request-theme
Difficulty 1/5 Under an hour Newbie friendliness 66/100
LizardByte/ThemerrDB#9575 ·
Maintainers usually reply within 1 day
-
author-page correction
Difficulty 2/5 1-3 hours Newbie friendliness 62/100
acl-org/acl-anthology#10599 · 1 comment ·
Maintainers usually reply within 1 day
-
Difficulty 2/5 1-3 hours Newbie friendliness 78/100
zilliztech/memsearch#818 ·
Maintainers usually reply within 1 day