Evidence
From specs, their links and their anchors Tracemoor derives evidence: which requirements are implemented and tested, which code is specified, who approved a spec, and what changed when. This section describes that evidence and how to export it.
Two views on the same data
The traceability matrix starts from the requirements. It has one row per
artifact of the first type in the trace chain (URS in GAMP 5) and follows
the links down the chain: which FS satisfy the requirement, which TC test
those FS, how many anchors the chain has. See
Traceability matrix.
Coverage starts from the code. For each code symbol it counts which artifact types anchor that symbol directly. Links between specs play no part. See Coverage.
The two views can differ. In the Weatherreport demo, URS-X32AND links to
FS-66EP13, which links to TC-K4W4D2. The matrix row is complete. The
symbol commands.rs::get_current_weather counts as trace complete in
coverage only because all three specs carry an anchor on it. A symbol that
only FS-66EP13 anchors stays partial, however complete the links are.
Which specs count
The matrix lists every requirement with its status and does not filter by status.
Coverage counts an anchor only when its spec has a counting status and the
anchor resolves (ok):
| View | Counting statuses |
|---|---|
| Auditor (default) | approved |
| Reviewer | draft, review, approved |
rejected and obsolete never count. With all specs still in draft or
review, the auditor view shows 0 %.
Approval and signatures
A profile can require an electronic signature for approved and rejected.
The GAMP 5 profile does. The signature records who decided, when, why, and
a hash of the spec body at that moment. It is written into the frontmatter
of the spec. See Signatures and audit trail.
Audit trail
Every change to a spec is recorded as an event: creation, edits, links, anchors, status changes, signatures, suspect raised and resolved. Each event contains the hash of the previous one, so a changed, deleted or reordered event is detectable. See Audit trail.
Audit bundles
An audit bundle freezes the state for an audit: matrix, specs, audit trail, profile and a hash of the analysed code, as a ZIP with a PDF report and a manifest of hashes. See Audit bundles.
Where the evidence is stored
Part of the evidence lives in files of the exploration and travels with git. The rest lives in the analysis database, which belongs to one machine. Analysis › Clear Cache & Re-analyze deletes that database.
| Evidence | Stored in | Shared through git | After Clear Cache |
|---|---|---|---|
| Specs, links, anchors | specs/**/*.md | yes | read again from the files |
| Signatures | frontmatter of each spec (approval_signature) | yes | kept |
| SSH public keys of signers | specs/_signers.yaml | yes | kept |
| Audit bundles (ZIP) | specs/_audits/ | yes | kept |
| Audit trail | analysis database | no | deleted |
| List of audit bundles and their reference hashes | analysis database | no | deleted, the Audit tab is empty and Verify no longer works |
| Anchor hashes and suspect state | analysis database | no | deleted, every anchor starts unsuspicious again |
| Signing method of the project | analysis database | no | reset to the profile default |
| Signer identity and passphrase | user account on this machine | no | kept |
On a fresh clone the same applies: the files are there, the audit trail and the suspect state are not. Create an audit bundle before you clear the cache or hand an exploration to someone else, and commit it.