Skip to content
TRACE ALM Documentation

What TRACE ALM is

TRACE ALM — Traceability, Requirements, and Compliance Engine — is the integrated set of open-source tools, internal scripts, and process conventions that, together, replace what a single commercial ALM suite would do for a regulated medical-software project. It is currently deployed against BioFlow Pro, a Flutter/Dart Windows desktop EEG-recording app, and is designed so the same stack can be lifted onto future regulated products with minimal per-project work.

The system addresses ISO 62304, ISO 14971, ISO 13485, IEC 81001-5-1, and 21 CFR Part 11 requirements through automated traceability between requirements, tests, change records, and reviewer approvals — with cryptographic content fingerprints binding each approval to the exact content that was approved.

The flow at a glance

Section titled “The flow at a glance”

What each piece does, in one line

Section titled “What each piece does, in one line”
  • StrictDoc — authoring tool for the requirements and test specifications. Source of truth for the three-tier requirements graph (regulatory-docs/10_system.sdoc for system / stakeholder requirements, regulatory-docs/11_srs.sdoc for software requirements, regulatory-docs/20_architecture.sdoc for software architecture) and regulatory-docs/*.sdoc.
  • Post-processor — internal Python tool that joins requirements to test results, classifies review state, detects drift, and renders the Requirements Traceability Matrix (RTM).
  • VisionTrace — internal AI-driven UI-automation framework that runs system tests against the installed BioFlow exe.
  • Allure — open-source test-reporting framework that turns raw test JSON into a browseable dashboard with screenshots and step-by-step LLM reasoning.
  • Auto-stamp App — dedicated GitHub App (bioflow-autostamp) that, when a regulated PR merges, computes the SHA-256 of each touched requirement and records the approver’s identity into the .sdoc file.
  • Signet — internal tool for formal 21 CFR Part 11 signatures on release approvals and verification records.

How approval and traceability close the loop

Section titled “How approval and traceability close the loop”
  1. A developer edits one of the regulatory-docs/*.sdoc documents (system / SRS / architecture, or one of the test specs) and opens a pull request.
  2. The PR pipeline runs Dart unit + integration tests, builds the real release installer, silently installs it, runs VisionTrace system tests against the installed exe, and feeds every test result into the post-processor.
  3. The post-processor renders the RTM — every requirement linked to its verifying tests with pass/fail status — and runs the --fail-on-suspect gate that blocks the merge if any requirement has drifted from its last approved content without a covering change record.
  4. A code-owner reviewer (per .github/CODEOWNERS) approves the PR.
  5. On merge, the auto-stamp Action triggers. It reads who approved, computes the canonical hash of every touched requirement, and writes REVIEWED_HASH + REVIEWED_BY back into the .sdoc file as a direct push to main.
  6. From that moment, any future change to a stamped requirement that isn’t covered by a change record will be detected by the post-processor and will block its PR.
  7. At release time, Signet overlays formal 21 CFR Part 11 signatures on the release record, completing the regulatory chain back to the deployed binary.

The cryptographic property that makes this defensible: the REVIEWED_HASH ties an approval event to the exact content it approved. If the content changes after the stamp, the hash mismatches; the next CI run sees this and blocks any PR built on a baseline that’s drifted without an authorising change record.

Where to go next

Section titled “Where to go next”