> ## 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.
# Customer and Auditor Handoff
> Handing an evidence pack to an external auditor. The cover letter, the disclaimer, read-only project access, what they typically request next.
# Customer and Auditor Handoff
You have generated an [evidence pack](/evidence/generation). The next step is delivering it to the recipient — a notified body assessor, a certification-body auditor, a downstream customer's compliance team, or your own internal QA-gate reviewer.
This page is the playbook.
## What to hand over
| Asset | Why |
| --------------------------------------------------- | ---------------------------------------------------------------------------------------------------------- |
| The **PDF** | Primary read-through. Auditors skim this first. |
| The **ZIP** | Their tooling will operate on this; keep it accessible. |
| The **ReqIF** | If they run Polarion, Jama, codeBeamer, or DOORS. Ask first. |
| A **cover letter** | Frames the pack, what it covers, what it does not, and how to verify. |
| A **read-only share link** to the Roboticks project | So they can explore the live traceability matrix, drill into a specific test, or pull additional evidence. |
| The **public verification key** | So they can verify signatures offline if they prefer. |
The dashboard's **Share** flow on the release page bundles every one of these into a single signed delivery URL that:
* Lists the pack with download buttons for each format.
* Embeds the read-only project view (their access is constrained to this release's data only).
* Displays the cover letter (editable per delivery).
* Auto-expires after a duration you choose (default 90 days; some auditors want longer).
* Is revocable.
## The cover-letter template
The platform pre-fills a cover letter from the release metadata. The boilerplate is yours to edit per delivery, but the structure is fixed for consistency. The template:
> **Roboticks Evidence Pack — Release `{tag}`**
>
> Dear `{recipient_name}`,
>
> The attached evidence pack documents the verification evidence for release `{tag}` of `{project_title}`, cut on `{verified_at}` and shipped on `{shipped_at}`. The pack is scoped to the commit set:
>
> {commit_set_table}
>
> The pack contains:
>
> * `{n_requirements}` requirements snapshotted at release time, of which `{n_covered}` are confirmed by at least one passing test, `{n_gaps}` are open gaps, and `{n_acknowledged}` are acknowledged gaps with documented rationale.
> * `{n_tests}` test runs, of which `{n_passed}` passed, `{n_failed}` failed (resolved before promotion), and `{n_skipped}` were skipped per documented exclusion criteria.
> * `{n_mcaps}` MCAP recordings, available in S3 (signed URLs below; valid `{presigned_validity}`).
> * Coverage reports (gcov / lcov for C++, coverage.py for Python).
> * Static-analysis findings (SARIF 2.1.0).
> * SBOM in SPDX and CycloneDX formats.
> * The full requirements snapshot and traceability matrix for this release.
>
> **Pack integrity:** The pack's manifest is signed with Ed25519 key `{key_id}` and chains to the previous pack via SHA-256. Verify with `rbtk evidence verify epak_{pack_id}` or use the public verification key at `{public_key_url}`.
>
> **Important disclaimer:** Roboticks is audit-readiness tooling. The platform assembles evidence; it does not issue conformity assessments and is not a certified or qualified toolchain (e.g., not DO-178C TQL, not ISO 26262-8 TCL). The interpretations of the cited standards reflected in the requirement derivations are the responsibility of `{org_name}` and have not been independently certified. Verify the regulatory interpretations against the standard text and your assessment.
>
> If you require additional evidence — earlier release packs, MCAP retrievals from cold storage, specific test re-runs — contact `{contact_email}`.
>
> Sincerely,
> `{signer_name}`, `{signer_role}`
## Read-only project access
The read-only share link grants a scope-limited view of the Roboticks project:
| Allowed | Forbidden |
| -------------------------------------------------------- | -------------------------------------- |
| Browse the release's pinned requirements | Browse other releases not in the share |
| Browse the release's traceability matrix | Edit anything |
| Drill into individual tests, see logs, see MCAP previews | Trigger new test runs |
| Verify the hash chain | Generate new evidence packs |
| Export the pack in any format you have enabled | Access organisation-level settings |
| See pinned-standards summaries for the release | See other projects' data |
Access is logged audibly: every page view, MCAP retrieval, and download is recorded against the recipient's email and surfaces in the dashboard's **Audit Access Log**. Many regulators want this log as part of the technical file.
## What auditors typically request next
In approximate frequency order:
1. **Restore a specific MCAP from Deep Archive.** Typically a particular failure scenario or a particular edge-case sim run they want to inspect. Initiate with `rbtk evidence restore --include-mcaps`.
2. **Re-verification against the same commit set.** "Re-run the tests, show me they still pass." This is the [pure replay](/evidence/release-scoping#re-verification-semantics) workflow.
3. **A comparison pack against an earlier release.** Showing what changed and what verification stayed stable. Generate a second pack at the earlier release and diff in the auditor's tooling.
4. **Drill into a specific requirement-to-test link.** The read-only project view answers this directly.
5. **A signed statement of independence** — that Roboticks the company is independent from the customer's verification activities. Available on request; we provide a templated letter.
6. **The Roboticks platform's own SOC 2 / ISO 27001 attestation.** Provided under NDA via our [Trust page](https://roboticks.io/trust).
## Pre-flight checklist
Before sending the pack, confirm:
* [ ] Release is in state `verified` or `shipped`.
* [ ] Hash chain verifies (`rbtk evidence verify` returns success).
* [ ] All requested standards are pinned with the correct edition.
* [ ] No open gaps that are not explicitly acknowledged with documented rationale.
* [ ] The cover letter is edited for this specific recipient.
* [ ] Share link expiry is set sensibly (default 90 days; extend for slow auditors).
* [ ] Public-key URL works (curl it).
* [ ] Test the auditor link from a fresh browser session before sending.
## The disclaimer is non-negotiable
The canonical disclaimer (see [Disclaimer](/standards/disclaimer)) is embedded in every pack and reproduced in every cover letter. Do not remove it. The disclaimer is what protects you legally when an auditor — months or years later — claims they were misled about what Roboticks evidence does and does not establish.
**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.
## Next steps
Full end-to-end workflows by certification scenario.
What the auditor will check.
Process and timing for cold-storage retrievals.
What we map against; how to pin a standard.