> ## Documentation Index
> Fetch the complete documentation index at: https://docs.roboticks.io/llms.txt
> Use this file to discover all available pages before exploring further.
# Traceability Audit Prep
> Pre-audit checklist — matrix completeness, gap closure, requirement snapshotting, evidence-pack integrity, connector configuration review, access controls.
# Traceability Audit Prep
Run this checklist the week before the auditor arrives. It catches the issues that typically delay an audit by days — incomplete matrices, stale connectors, unverifiable hash chains, access-control gaps — when fixing them before the auditor sees them takes hours.
Applies whether the auditor is external (notified body, certification body) or internal (QA leadership, customer compliance team).
**Roboticks is audit-readiness tooling, not a certified toolchain.** We assemble the evidence your notified body, certification body, or QA process ingests. We do not replace tool qualification (DO-178C, ISO 26262-8 TCL) and we do not issue conformity assessments. Verify the regulatory interpretations on this page against the standard text and your accredited assessor.
## When to run
| Trigger | Lead time |
| ------------------------------------ | ---------------- |
| External audit scheduled | 1–2 weeks before |
| Customer compliance review scheduled | 1 week before |
| Annual surveillance audit | 2 weeks before |
| Sign-off on a major release | 2 days before |
| Just to know where you stand | Monthly |
## The checklist
### 1. Matrix completeness
* [ ] Open the [traceability matrix](/traceability/matrix) for the release under audit.
* [ ] Filter to **uncovered requirements**. Each one is a potential audit finding.
* [ ] For each uncovered requirement: either add a confirming test or document as acknowledged gap with rationale.
* [ ] Filter to **failing tests on the release**. Each is a potential audit blocker.
* [ ] Filter to **requirements with only failed tests** confirming them. These count as uncovered for audit purposes — close them.
### 2. Acknowledged gap rationale
* [ ] List every acknowledged gap in the release.
* [ ] Confirm each has documented rationale visible in the requirement record.
* [ ] Confirm the rationale is defensible to the auditor — "we'll get to it" is not a rationale; "this clause does not apply to our product class because…" is.
* [ ] Get sign-off from the safety engineer or compliance lead on safety-typed acknowledged gaps.
### 3. Requirement snapshotting
* [ ] Confirm the release is in `verified` or `shipped` state (snapshots are taken at `verified` transition).
* [ ] Confirm every requirement in the snapshot has a `derives_from` referencing a pinned standard (where applicable to your project — purely internal requirements may legitimately have an empty `derives_from`).
* [ ] Confirm `derives_from` references the **correct edition** of each standard — not an obsolete one.
### 4. Evidence-pack integrity
* [ ] Generate the evidence pack for the release if not already generated:
```bash theme={null}
rbtk test evidence-pack --release --format pdf,zip,reqif
```
* [ ] Verify the hash chain:
```bash theme={null}
rbtk evidence verify
rbtk evidence verify-chain --project /
```
Both should pass with no errors. A verification failure must be resolved before the audit.
* [ ] Open the PDF and skim. The cover page, table of contents, requirements section, and disclaimer should all render correctly. Customised templates (Enterprise) should render with the correct branding.
* [ ] Confirm any MCAPs the auditor might want are either in hot storage (90-day window) or that you have time to restore from Glacier (Standard: 9–12 hours; Bulk: 48 hours — see [Archive](/evidence/archive)).
### 5. Connector configuration review
* [ ] List active [BYO connectors](/integrations/overview) for the project.
* [ ] Confirm each connector last ran successfully within the last 24 hours. A connector that broke after the most recent verification leaves stale data in the pack.
* [ ] For Polarion / Jama / codeBeamer / DOORS connectors: confirm the requirement-snapshot import matches the version in the upstream system at release-cut time.
* [ ] For LDRA / Polyspace / Coverity: confirm SARIF output is current and present in the pack.
### 6. Standards-feed posture
* [ ] List pinned standards and check for **open amendment alerts** not yet triaged.
* [ ] For any open amendment: either complete triage before the audit, or document the open alert with a triage plan and target date.
* [ ] Auditors often check the feed posture as a signal of overall hygiene; un-triaged amendments are a soft warning sign.
### 7. Access controls
* [ ] Review project member list. Remove members who no longer need access.
* [ ] Review **read-only share links** for the release. Revoke any that have served their purpose.
* [ ] Generate a fresh read-only share link for the auditor with a sensible expiry (default 90 days; extend to 180 if your audit cycle is slow).
* [ ] Test the share link from a fresh browser session to confirm it works and scopes correctly.
### 8. Sign-off records
* [ ] If your release-state machine requires sign-off, confirm every required sign-off is recorded.
* [ ] Each sign-off should have a name, role, timestamp, and (recommended) comment.
* [ ] For external audits: confirm the comment quality — "approved" is weak; "approved with awareness of acknowledged gap REQ-217 per safety engineer assessment dated YYYY-MM-DD" is auditable.
### 9. Risk-assessment linkage
* [ ] Confirm `hazards.yaml` is current and consistent with the safety engineer's risk-assessment narrative.
* [ ] Confirm every hazard has at least one mitigating requirement (`realised_by_requirements`).
* [ ] For any hazard without mitigation: confirm the risk assessment documents why (e.g., risk acceptable without further mitigation, or mitigation is purely procedural and lives in instructions for use).
### 10. Cover letter and handoff
* [ ] Draft the cover letter from the template (see [Customer handoff](/evidence/customer-handoff#the-cover-letter-template)).
* [ ] Edit for the specific auditor and audit scope.
* [ ] Confirm the disclaimer is present.
* [ ] Prepare the pack-delivery method (signed share link, secure file transfer, in-person delivery).
* [ ] Brief the engineers who will be in the audit room. They should know which sections of the pack to point to for which questions.
## Post-audit hygiene
After the audit:
* [ ] Record audit findings (if any) as work items in the project.
* [ ] Schedule re-verification for any findings that require fix-and-re-verify.
* [ ] Update the rationale on any acknowledged gaps the auditor scrutinised (the auditor's questions are useful input).
* [ ] Revoke the auditor's share link if they no longer need it (or extend if the audit is incomplete).
* [ ] Retain the audit findings document alongside the evidence pack — they belong together in the 10-year archive.
## Common audit-blocker patterns
Things that surprise teams during audits and cause delays:
| Pattern | Catch by |
| ----------------------------------------------------------------------------------- | ------------------------------------------------------------------ |
| MCAP for the most-scrutinised scenario is in Glacier, audit is tomorrow | Pre-restore MCAPs for scenarios the auditor is likely to ask about |
| Connector failed quietly, SARIF is from last month | Step 5 |
| Requirement snapshot references retired edition of ISO 10218 (2011 instead of 2025) | Step 3 |
| 47 un-triaged feed amendments accumulated | Step 6 |
| Acknowledged gap rationale is "TBD" | Step 2 |
| Share link expired the day before the auditor's review meeting | Step 7 |
| Hash-chain verification fails because a pack was accidentally deleted from S3 | Step 4 — and address the IAM policy that allowed the deletion |
## Next steps
The cover letter and delivery mechanics.
What the auditor will check on integrity.
Amendment-triage hygiene.
The day-to-day discipline that prevents most pre-audit fire-drills.