Skip to main content

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

You have generated an evidence pack. 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

AssetWhy
The PDFPrimary read-through. Auditors skim this first.
The ZIPTheir tooling will operate on this; keep it accessible.
The ReqIFIf they run Polarion, Jama, codeBeamer, or DOORS. Ask first.
A cover letterFrames the pack, what it covers, what it does not, and how to verify.
A read-only share link to the Roboticks projectSo they can explore the live traceability matrix, drill into a specific test, or pull additional evidence.
The public verification keySo 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: 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:
AllowedForbidden
Browse the release’s pinned requirementsBrowse other releases not in the share
Browse the release’s traceability matrixEdit anything
Drill into individual tests, see logs, see MCAP previewsTrigger new test runs
Verify the hash chainGenerate new evidence packs
Export the pack in any format you have enabledAccess organisation-level settings
See pinned-standards summaries for the releaseSee 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 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.

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) 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

Compliance patterns

Full end-to-end workflows by certification scenario.

Hash chain verification

What the auditor will check.

Archive restore

Process and timing for cold-storage retrievals.

Standards coverage

What we map against; how to pin a standard.