Glossary
Terms specific to TRACE ALM, regulated software, or the integrated tool chain. For the canonical use of each in context, follow the cross-link.
auto-stamp
Section titled “auto-stamp”The internal Action (tooling page) that fires when a regulated PR merges and writes REVIEWED_HASH + REVIEWED_BY into the touched .sdoc files. Provides per-PR content-level approval recording.
baselined
Section titled “baselined”A regulated artefact (typically a requirement) is baselined when it carries a stamped REVIEWED_HASH matching its current content. Subsequent edits without a covering change record are detected as drift and blocked at merge.
bioflow-autostamp
Section titled “bioflow-autostamp”The specific GitHub App that performs auto-stamping for the BioFlow Pro repo. Other projects using TRACE ALM register their own equivalently-named App (applying-to-new-projects).
change record
Section titled “change record”A Markdown file at changes/CR-NNNN.md with YAML frontmatter naming the affected requirement UIDs and the change state (proposed / approved / implemented / verified). Authorises drift on baselined items so the post-processor’s --fail-on-suspect gate doesn’t block the merge (change-baselined-requirement workflow).
CODEOWNERS
Section titled “CODEOWNERS”The .github/CODEOWNERS file mapping repo paths to required reviewers (CODEOWNERS playbook). When combined with the Require review from Code Owners branch-protection toggle, GitHub blocks PR merges on regulated paths until the listed owner approves.
CSA (Computer Software Assurance)
Section titled “CSA (Computer Software Assurance)”FDA guidance terminology for proving that software used in a regulated workflow is fit for purpose. Tool qualification packages — outlined in the skill file — are CSA deliverables for the post-processor, auto-stamp, and other regulated tools.
DHF (Design History File)
Section titled “DHF (Design History File)”ISO 13485 / ISO 62304 term for the long-term archival record of a medical device’s design history. TRACE ALM’s release evidence bundles + Signet signature manifests are deliverables that go into the DHF.
IT (integration test)
Section titled “IT (integration test)”A test that exercises multiple real components together (e.g. AppDatabase + real SQLite + real filesystem). Specified in regulatory-docs/31_integration_tests.sdoc with prefix IT-. See skill file §3.2.
MID (Machine ID)
Section titled “MID (Machine ID)”StrictDoc’s auto-generated stable identifier for each requirement. Survives renames; persists across the lifecycle of an item. Distinct from the human-readable UID (e.g. SRS-001).
post-processor
Section titled “post-processor”The internal Python tool (tooling page) at tools/post_processor/rtm.py that joins requirements to test results and renders the RTM. Also the source of the hash function that auto-stamp re-uses.
REVIEWED_HASH / REVIEWED_BY
Section titled “REVIEWED_HASH / REVIEWED_BY”Two fields on every regulated .sdoc requirement. REVIEWED_HASH is the SHA-256 of the canonical reviewable content; REVIEWED_BY is the @-prefixed identity of the qualified reviewer who approved that exact content. Stamped automatically by the auto-stamp Action; never authored by hand.
RTM (Requirements Traceability Matrix)
Section titled “RTM (Requirements Traceability Matrix)”The HTML deliverable produced by the post-processor that shows every requirement linked to its verifying tests with pass/fail status. The browseable form of the regulated chain.
Signet
Section titled “Signet”The internal tool for formal 21 CFR Part 11 signatures on release approvals and verification records (tooling page). Documented separately at <SIGNET_DOCS_URL>.
SOUP (Software of Unknown Provenance)
Section titled “SOUP (Software of Unknown Provenance)”ISO 62304 term for off-the-shelf software dependencies whose internal quality processes aren’t directly knowable. TRACE ALM components like StrictDoc, Allure, and the Allure CLI are SOUP and are tracked in the SOUP register (per dev-docs/strictdoc.md).
ST (system test)
Section titled “ST (system test)”A test that exercises the full deployed application end-to-end via UI automation. Specified in regulatory-docs/32_system_tests.sdoc with prefix ST-. Implemented in TRACE ALM via VisionTrace.
StrictDoc
Section titled “StrictDoc”Open-source requirements-management tool (tooling page). Source of truth for the three-tier requirements graph (regulatory-docs/10_system.sdoc, regulatory-docs/11_srs.sdoc, regulatory-docs/20_architecture.sdoc) and regulatory-docs/*.sdoc.
suspect-native / suspect-inherited / change-in-progress / reviewed / unreviewed / inactive
Section titled “suspect-native / suspect-inherited / change-in-progress / reviewed / unreviewed / inactive”The six review states the post-processor classifies every regulated artefact into. suspect-native and suspect-inherited block merges via --fail-on-suspect. See change-baselined-requirement workflow for full semantics.
TRACE ALM
Section titled “TRACE ALM”The integrated set of open-source tools, internal scripts, and conventions that, together, replace what a single commercial ALM suite would do. Acronym: Traceability, Requirements, And Compliance Engine. Currently deployed against BioFlow Pro; designed to be reusable across regulated software products.
Human-readable identifier for a regulated artefact (e.g. SRS-001, IT-002, ST-005). Stable for the life of the item. Distinct from the StrictDoc-generated MID.
UT (unit test)
Section titled “UT (unit test)”A test that exercises one class or function in isolation with mocked dependencies. Specified in regulatory-docs/30_unit_tests.sdoc with prefix UT-. See skill file §3.2.
VisionTrace
Section titled “VisionTrace”Internal AI-driven UI-automation framework (tooling page). Records and replays Windows desktop app workflows; used for ST testing.