Tool Qualification
IQ/OQ Validation Package
RTMify ships a versioned IQ/OQ kit with every Trace release. Your quality team can qualify Trace as a software tool within your QMS in under an hour. You don't build the protocol. We ship it.
What's in the package
| File | What it is |
|---|---|
| OQ fixture (.xlsx) | Controlled workbook with 25 items across 4 tabs. Contains intentional gaps, intentional warnings, and valid chains for positive verification. |
| golden.pdf, golden.docx, golden.md | Pre-verified reference outputs generated by RTMify against the fixture. Your run must produce outputs equivalent to these. |
| golden-gaps.json | Machine-readable gap oracle: every warning code, the item IDs that trigger it, and the total warning count. Used for structural diff in CP-OQ-04 and CP-OQ-05. |
| IQ/OQ Protocol (PDF) | Step-by-step procedure with 8 numbered checkpoints, pass/fail fields for each, and signature blocks for the executor and QA reviewer. The document is self-contained. No external SOPs are required to execute it. |
| Evidence Record (PDF) | Blank form your team completes during execution. File the completed record, your generated outputs, and comparison evidence in your quality system. |
| checksums.txt | SHA-256 hashes for every platform binary covered by this release: macOS, Windows, and Linux. Used to satisfy the IQ installation verification step. |
How the fixture was designed
Every row in the OQ fixture exists for a reason. The fixture covers all four tabs of the RTMify schema (User Needs, Requirements, Tests, and Risks) with 25 items total. Item IDs follow the OQ- prefix convention so they are immediately distinguishable from any customer data and cannot be confused with live items.
The fixture contains three categories of content:
- Intentional gaps. Dangling cross-references (a requirement pointing to a test that doesn't exist), orphaned items with no upstream trace, and deliberately missing links that should trigger E801 (ref not found) and E1206 (chain gap) codes.
- Intentional warnings. Requirements without "shall" (E703), compound requirements with multiple clauses (E704), and a risk item where residual score exceeds initial score (E710). These verify Trace's semantic validation layer.
- Valid chains. A subset of items with complete, correctly-typed trace links. These provide positive verification: Trace must report them clean, with no warnings.
The golden-gaps.json file captures the exact expected diagnostic output for the fixture: which codes fire, against which item IDs, and the total warning count. This is the ground truth for OQ acceptance.
Gap taxonomy
RTMify Trace validates your workbook in 8 layers. The codes relevant to requirements quality and traceability integrity are in layers 6 (semantic) and 7 (cross-reference). Chain completeness codes, which are required under DO-178C, IEC 62304, and ISO 26262, are in layer 8 (profile traceability).
| Code | Description | Severity |
|---|---|---|
| Semantic validation (E7xx) | ||
| E703 | Requirement has no "shall" | WARN |
| E704 | Compound requirement: multiple "shall" clauses | WARN |
| E705 | Vague or ambiguous term in requirement statement | WARN |
| E706 | Obsolete requirement still has active trace links | WARN |
| E708 | High-risk score (>12) with no mitigation | WARN |
| E710 | Residual risk score exceeds initial risk score | WARN |
| Cross-reference (E8xx) | ||
| E801 | Cross-reference target not found in the graph | ERROR |
| E802 | Cross-reference target has an unexpected node type | ERROR |
| Profile traceability (E12xx) | ||
| E1201 | Traceability chain is incomplete for this node | WARN |
| E1202 | Design Input has no linked Design Output | WARN |
| E1203 | High-level requirement has no linked low-level requirement | WARN |
| E1206 | Gap in traceability chain | WARN |
All codes are documented at rtmify.io/errors/E<code>. The full catalog covers 8 validation layers, from filesystem checks (E1xx) through profile traceability (E12xx).
How acceptance works
The protocol has two levels of acceptance: machine-verifiable and human-verified.
Machine-verifiable acceptance uses the JSON gap oracle. You run Trace against the OQ fixture and compare your customer-gaps.json output to golden-gaps.json using a structural diff: same codes present, same item IDs listed under each code, same total warning count. This comparison is deterministic and scriptable. Byte-for-byte PDF comparison is not used because PDF output includes timestamps and renderer metadata that vary across runs and platforms.
Human-verified acceptance covers the 8 numbered checkpoints in the protocol:
| Checkpoint | What is checked | How to verify |
|---|---|---|
| CP-OQ-01 | Binary hash matches published value | shasum -a 256 rtmify-trace and compare to checksums.txt |
| CP-OQ-02 | Version string matches expected release | rtmify-trace --version returns correct string |
| CP-OQ-03 | Fixture processing exits cleanly | Run Trace on OQ fixture; exit code is 0 |
| CP-OQ-04 | Warning count matches golden | warning_count in customer-gaps.json equals golden value |
| CP-OQ-05 | Gap codes and item IDs match golden | Structural diff of customer-gaps.json against golden-gaps.json. The same codes must be present with the same OQ-item IDs listed under each. |
| CP-OQ-06 | Markdown output matches golden | diff customer.md golden.md returns no differences |
| CP-OQ-07 | DOCX section structure matches golden | Section headings and node count in customer.docx match golden.docx |
| CP-OQ-08 | PDF is well-formed and page count matches | Page count matches golden.pdf; document opens without errors |
How version binding works
The package version matches the Trace release. The fixture, golden outputs, protocol, and checksums are all regenerated and re-verified for every release. The package filename encodes the release identifier (for example, RTMify_Trace_Validation_Package_v20260314-b.zip) so your QMS record clearly identifies which Trace release was qualified.
When you upgrade Trace, re-execute the protocol with the new release's package. Each qualification is a discrete, traceable event in your quality system. The previous record is not superseded. You keep both.
Which standards require tool qualification
Tool qualification requirements vary by standard and tool classification, but the common thread is that any software tool that can introduce errors into, or fail to detect errors in, a safety-relevant deliverable must be qualified.
- DO-178C / DO-330. Tool qualification applies to verification tools and development tools that automate activities otherwise requiring independent review. RTMify Trace automates traceability analysis.
- IEC 62304. Tools used in the software development process shall be validated. The extent depends on the software safety class.
- ISO 13485 §7.6. Software used to monitor or measure quality system activities shall be validated prior to use, with re-validation following changes.
- ISO 26262 Part 8. Software tools used in the development of safety-related systems shall be qualified according to the tool confidence level (TCL).
- AS9100. Monitoring and measuring equipment shall be controlled to ensure its suitability for use. Many AS9100 QMSes extend this to software tools used in verification activities.
The IQ/OQ package is designed to satisfy the evidence requirements across all of these frameworks. The protocol PDF describes which checkpoints map to which standard requirements.
Included with every Trace purchase
The validation package ships automatically with your license. No separate request needed. If you need a custom protocol tailored to your SOP templates or a specific deployment environment, contact us.