Skip to content
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension


Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
98 changes: 41 additions & 57 deletions .github/workflows/release.yml
Original file line number Diff line number Diff line change
Expand Up @@ -45,6 +45,43 @@ jobs:
echo "release_target_commit=$release_target_commit" >> "$GITHUB_OUTPUT"
echo "Release target commit: $release_target_commit"

- name: Check out Biosigpy conformance declaration
uses: actions/checkout@v4
with:
repository: BSICoS/biosigpy
ref: main
path: downstream/biosigpy
persist-credentials: false

- name: Check out Biosigmat conformance declaration
uses: actions/checkout@v4
with:
repository: BSICoS/biosigmat
ref: main
path: downstream/biosigmat
persist-credentials: false

- name: Verify downstream conformance pins
env:
RELEASE_TARGET_COMMIT: ${{ steps.release-target.outputs.release_target_commit }}
run: |
python - <<'PY'
import json
import os
from pathlib import Path

expected_commit = os.environ["RELEASE_TARGET_COMMIT"]
for implementation in ("biosigpy", "biosigmat"):
manifest_path = Path("downstream") / implementation / "conformance.json"
manifest = json.loads(manifest_path.read_text(encoding="utf-8"))
actual_commit = manifest["biosiglib"]["commit"]
if actual_commit != expected_commit:
raise SystemExit(
f"{implementation} declares conformance with {actual_commit}, "
f"not release target {expected_commit}"
)
PY

- name: Set up Python
uses: actions/setup-python@v5
with:
Expand All @@ -64,7 +101,10 @@ jobs:
run: python -m unittest discover -s tests -v

- name: Validate Biosiglib
run: python tools/validate_specs.py
run: |
python tools/validate_specs.py \
--manifest downstream/biosigpy/conformance.json \
--manifest downstream/biosigmat/conformance.json

- name: Check generated documentation
run: python tools/generate_docs.py --check
Expand Down Expand Up @@ -99,59 +139,3 @@ jobs:
echo "Release tag $VERSION points to $tag_commit, expected $RELEASE_TARGET_COMMIT" >&2
exit 1
fi

- name: Dispatch Biosigmat propagation
env:
GH_TOKEN: ${{ secrets.BIOSIGLIB_PROPAGATION_TOKEN }}
RELEASE_TARGET_COMMIT: ${{ steps.release-target.outputs.release_target_commit }}
VERSION: ${{ inputs.version }}
run: |
if [[ -z "${GH_TOKEN:-}" ]]; then
echo "BIOSIGLIB_PROPAGATION_TOKEN is required to dispatch Biosigmat propagation" >&2
exit 1
fi
python - <<'PY' > dispatch-payload.json
import json
import os
import sys

json.dump(
{
"event_type": "biosiglib-release",
"client_payload": {
"release": os.environ["VERSION"],
"commit": os.environ["RELEASE_TARGET_COMMIT"],
},
},
sys.stdout,
)
PY
gh api --method POST /repos/BSICoS/biosigmat/dispatches --input dispatch-payload.json

- name: Dispatch Biosigpy propagation
env:
GH_TOKEN: ${{ secrets.BIOSIGPY_PROPAGATION_TOKEN }}
RELEASE_TARGET_COMMIT: ${{ steps.release-target.outputs.release_target_commit }}
VERSION: ${{ inputs.version }}
run: |
if [[ -z "${GH_TOKEN:-}" ]]; then
echo "BIOSIGPY_PROPAGATION_TOKEN is required to dispatch Biosigpy propagation" >&2
exit 1
fi
python - <<'PY' > dispatch-payload.json
import json
import os
import sys

json.dump(
{
"event_type": "biosiglib-release",
"client_payload": {
"release": os.environ["VERSION"],
"commit": os.environ["RELEASE_TARGET_COMMIT"],
},
},
sys.stdout,
)
PY
gh api --method POST /repos/BSICoS/biosigpy/dispatches --input dispatch-payload.json
7 changes: 2 additions & 5 deletions AGENTS.md
Original file line number Diff line number Diff line change
Expand Up @@ -63,10 +63,7 @@ Relative tolerances are not part of the initial design.
- examples and workflows remain under examples/;
- all current public functions are considered stable.

17. Current pilot specifications:
- hrv.tdmetrics;
- ecg.pantompkins;
- ecg.sloperange.
17. The generated specification catalog is the authoritative inventory. Do not maintain manual subsets of current specification IDs in policy or overview documents.

18. For hrv.tdmetrics:
- the canonical input dtk is the cleaned beat-to-beat or pulse-to-pulse interval sequence in seconds;
Expand All @@ -84,7 +81,7 @@ Relative tolerances are not part of the initial design.

22. All local Python tooling in Biosiglib must run inside the repository-local `.venv`. AI agents must create `.venv` when it is absent, invoke the `.venv` Python executable explicitly, and never commit `.venv` or generated Python caches. `requirements-dev.txt` remains the dependency declaration for Biosiglib tooling. CI environments, when introduced later, must install dependencies in a clean environment and must not reuse the local `.venv`. Biosigpy will also use its own independent repository-local `.venv` when its package structure is created.

23. Each implementation repository will contain a machine-readable conformance manifest validated against `schemas/implementation-manifest.schema.json`. The manifest must pin an exact Biosiglib commit. Its `specifications` field is an object keyed by canonical Biosiglib specification ID; each value contains the implementation status and optional implementation-specific metadata, and object keys guarantee one entry per specification ID. `conformant` may only be declared after all applicable conformance cases pass. Implementation versions remain independent from Biosiglib versions, and no per-algorithm version is used at this stage.
23. Each implementation repository contains a machine-readable conformance manifest validated against `schemas/implementation-manifest.schema.json`. The manifest pins one exact Biosiglib commit and declares conformance with every specification in that commit. Every shared case must be executed; partial support and implementation roadmaps belong in issues and pull requests. Implementation versions remain independent from Biosiglib versions, and no per-algorithm version is used.

24. Implementation manifests must be validated through Biosiglib's `tools/validate_specs.py --manifest PATH` command instead of duplicating schema-validation code in implementation repositories.

Expand Down
9 changes: 8 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,14 @@ The format is based on Keep a Changelog, and this project adheres to Semantic Ve
- Added the normative `ecg.baselineremove` contract, eight focused shared cases, and a scientific note covering one-based fiducial normalization, half-away-from-zero rounding, post-rounding sorting and deduplication, boundary-truncated local means, even-window expansion, reduced-degree and not-a-knot spline behavior, endpoint extrapolation, explicit zero- and one-valid-fiducial outcomes, and finite-real input requirements.
- Added the Meyer and Keiser 1977 ECG baseline-noise publication while distinguishing its PR-segment and cubic-spline rationale from empirical Biosigmat compatibility rules.

This is a MINOR change because it adds a compatible `ecg.baselineremove` specification and conformance profile without changing a released contract. Biosigmat and Biosigpy require adaptation and must pass the applicable shared cases before declaring this specification conformant.
### Changed

- Simplified implementation conformance manifests to one total declaration against an exact Biosiglib commit. Removed per-specification statuses, entry points, notes, duplicated repository and release metadata, and optional implementation versions.
- Made the manifest schema URL a checked derivative of the declared Biosiglib commit.
- Changed release coordination so Biosiglib can only publish a commit already pinned by both Biosigmat and Biosigpy.
- Removed unused draft statuses from informative scientific notes and replaced manual specification subsets with the generated authoritative catalog.

This is a MAJOR change because the implementation-manifest schema and release coordination contract are incompatible with previous releases. It also adds the compatible `ecg.baselineremove` specification; Biosigmat and Biosigpy must conform to the complete release target before Biosiglib is published.

## v1.4.0 - 2026-08-06

Expand Down
6 changes: 3 additions & 3 deletions README.md
Original file line number Diff line number Diff line change
Expand Up @@ -21,19 +21,19 @@ Biosiglib defines the expected scientific and computational behavior of public a

The generated documentation site is available at [https://bsicos.github.io/biosiglib/](https://bsicos.github.io/biosiglib/).

The website is generated from the JSON specifications. The JSON files remain the normative source of truth for algorithm behavior, inputs, outputs, units, defaults, missing-value handling, edge cases, tolerances, and conformance status.
The website is generated from the JSON specifications. The JSON files remain the normative source of truth for algorithm behavior, inputs, outputs, units, defaults, missing-value handling, edge cases, and tolerances. Implementations declare total conformance with one exact Biosiglib commit.

## Local validation

See [docs/development.md](docs/development.md) for local setup and validation commands.

## Releases

See the [SemVer classification and release-readiness checklist](docs/releases.md) for release semantics and propagation details.
See the [SemVer classification and release-readiness checklist](docs/releases.md) for release semantics and coordinated conformance details.

## Project status

Biosiglib is under active development. The first development phase establishes the specification format, validation tooling, generated documentation, shared fixtures, conformance cases, and integration with Biosigmat and Biosigpy.
Biosiglib is under active development. The generated specification catalog is the authoritative inventory of its current algorithm contracts.

## License

Expand Down
25 changes: 8 additions & 17 deletions docs/conformance.md
Original file line number Diff line number Diff line change
Expand Up @@ -2,32 +2,23 @@

Conformance describes how a language-specific implementation declares and validates its relationship to Biosiglib.

Each implementation repository maintains a machine-readable implementation manifest, conventionally named `conformance.json`. The manifest records the implementation identity, implementation version, pinned Biosiglib release and commit, and the support status for each Biosiglib specification.
Each implementation repository maintains a machine-readable implementation manifest, conventionally named `conformance.json`. The manifest identifies the implementation and pins the exact Biosiglib commit used for conformance.

The manifest specification IDs must exactly match the specification IDs in the pinned Biosiglib commit. Every specification must therefore have an explicit status, including functionality that is only planned or intentionally unsupported. Manifest validation rejects both unknown IDs and omitted specifications.
The declaration is total: the implementation conforms to every specification in the pinned commit and must execute every shared conformance case. Partial support, roadmaps, and work in progress belong in issues and pull requests rather than in the conformance manifest.

## Statuses

Implementation manifests use the following statuses:

| Status | Meaning |
| --- | --- |
| `conformant` | The implementation supports the specification and all applicable conformance cases pass for the pinned Biosiglib release and commit. |
| `implemented` | The implementation has behavior for the specification, but full conformance has not yet been established or declared. |
| `planned` | Support is intended, but implementation work is not complete. |
| `unsupported` | The implementation does not support the specification and does not currently plan to expose it. |

`conformant` should only be used after validation has passed for the exact Biosiglib version and commit recorded in the manifest.
Passing the shared cases is executable evidence for the declaration. It does not make the cases a substitute for the complete normative JSON contracts.

## Exact Pinning

A downstream manifest must pin an exact Biosiglib commit. A semantic version alone is not enough because conformance must be reproducible against the precise specifications, schemas, fixtures, and conformance cases used during validation.
A downstream manifest pins one exact Biosiglib commit. A semantic version alone is not enough because conformance must be reproducible against the precise specifications, schemas, fixtures, and conformance cases used during validation.

The `$schema` URL is derived from the same commit so editors can load the matching schema. Biosiglib's validator rejects a schema URL whose commit differs from `biosiglib.commit`; contributors therefore maintain one normative pin.

The pinned release communicates the public release relationship. The pinned commit makes the validation target exact.
Implementation and Biosiglib release versions remain visible in their respective repositories and release notes. They are not duplicated in the conformance manifest.

## Validation Across Implementations

Biosigmat and Biosigpy validate their manifests and behavior against Biosiglib resources. Each implementation can keep its own public API style, internal architecture, error classes, and plotting tools, but its normative outputs and edge-case behavior must match the Biosiglib contracts within the declared tolerances.
Biosigmat and Biosigpy validate their manifests and behavior against Biosiglib resources. Each implementation can keep its own public API style, internal architecture, error classes, and plotting tools, but its normative outputs and edge-case behavior must match every contract in the pinned commit within the declared tolerances.

The shared Biosiglib validator checks repository specifications and can validate implementation manifests with:

Expand Down
14 changes: 7 additions & 7 deletions docs/ecosystem.md
Original file line number Diff line number Diff line change
Expand Up @@ -4,23 +4,23 @@ Biosiglib coordinates a small ecosystem of repositories with separate responsibi

| Repository | Role |
| --- | --- |
| [Biosiglib](https://github.com/BSICoS/biosiglib) | Source of truth for language-independent specifications, shared fixtures, conformance cases, validation tools, and release propagation metadata. |
| [Biosiglib](https://github.com/BSICoS/biosiglib) | Source of truth for language-independent specifications, shared fixtures, conformance cases, validation tools, and coordinated release policy. |
| [Biosigmat](https://github.com/BSICoS/biosigmat) | MATLAB implementation of the Biosiglib specifications. |
| [Biosigpy](https://github.com/BSICoS/biosigpy) | Python implementation of the Biosiglib specifications. |

Biosigmat and Biosigpy may expose idiomatic language-specific APIs. They do not need identical internal architecture, but they must preserve the normative behavior defined by Biosiglib.

## Release Propagation
## Conformance and Releases

Biosiglib releases are propagated downstream so each implementation can declare exactly which specification release and commit it conforms to.
Each implementation declares conformance with one exact Biosiglib commit. The declaration covers every specification in that commit; support is not selected algorithm by algorithm.

The release path is:

1. Biosiglib release.
2. Biosigmat propagation pull request.
3. Biosigpy propagation pull request.
1. Prepare and validate the Biosiglib contract commit.
2. Adapt Biosigmat and Biosigpy to that exact commit and merge both implementations after their complete suites pass.
3. Release Biosiglib only after both downstream manifests pin the release target commit.

The downstream pull requests update each implementation repository's `conformance.json` file. The implementations remain independently versioned, so a Biosigmat or Biosigpy release declares its supported Biosiglib version instead of sharing the Biosiglib version number.
The implementations remain independently versioned. Their conformance manifests record the reproducible commit relationship instead of mirroring the Biosiglib version number.

## Source Of Truth

Expand Down
4 changes: 1 addition & 3 deletions docs/index.md
Original file line number Diff line number Diff line change
Expand Up @@ -24,8 +24,6 @@ The repository is designed so humans can read the behavior while tools can valid

The current documentation covers:

* [`hrv.tdmetrics`](generated/specifications/hrv.tdmetrics.md) - time-domain beat or pulse variability metrics.
* [`ecg.pantompkins`](generated/specifications/ecg.pantompkins.md) - Pan-Tompkins-style ECG R-wave detection.
* [`ecg.sloperange`](generated/specifications/ecg.sloperange.md) - slope-range ECG-derived respiration.
See the generated [specification catalog](specifications.md) for the complete authoritative inventory of current contracts.

The initial pilots established the specification, fixture, conformance, and release patterns before the full Biosiglib scope expands across ECG, PPG, respiration, HRV, and other biomedical signal-processing tools.
Loading
Loading