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.

Evidence Packs

An evidence pack is the single artefact Roboticks produces for a release that an external auditor, internal QA gate, or certification body ingests. It pins every input that fed the verification run and every output that came out, in formats the certified toolchain already understands.
Generate one per release; archive for a decade or more. The pack is the contractual receipt that — on the day you shipped that commit set — every safety, functional, and performance requirement had a passing test behind it.

What is inside

A pack is a structured directory tree rendered into three deliverable formats. Every pack contains:
ArtefactSourceWhy it is there
Requirements snapshotImmutable copy of every pinned requirement at the moment of releaseThe auditor needs the exact text you verified against, not the latest
Traceability matrix subsetThe requirement × test grid for this release onlyProves coverage and surfaces any acknowledged gap
JUnit XMLsEvery test run that fed the release, with roboticks.confirms propertiesThe raw verification evidence
MCAP referencesSigned URLs into the hot or Glacier S3 pathThe bag files the tests recorded, retained per the archive policy
Logsstdout/stderr, runner logs, ROS2 node logsFailure forensics; required by many functional-safety standards
Coverage reportgcov / lcov for C++, coverage.py for PythonMandatory under most functional-safety regimes for SIL or ASIL items
SBOMSPDX 2.3 or CycloneDX 1.5Required by EU Cyber Resilience Act; auditor cross-checks for known-vulnerable components
Static-analysis findingsSARIF 2.1.0 from your scanner stackclang-tidy, cppcheck, Bandit, Semgrep, plus any BYO connector output (LDRA, Polyspace, Coverity)
Screenshots and clipsOptional. From sim runsVisual evidence reviewers find disproportionately persuasive
Manifestevidence_pack.manifest.jsonThe machine-readable index tying it all together

Three formats, one source of truth

The same pack renders three ways. The format you hand over depends on what the recipient ingests.
FormatWhat it isTier
PDFAudit-ready, paginated, with table-of-contents, requirement-by-requirement evidence pagesFree, Team, Enterprise
ZIPEvery raw file, the manifest, and a README.md describing the layoutFree, Team, Enterprise
ReqIFRound-trippable into Polarion, Jama, codeBeamer, DOORSTeam, Enterprise
ReqIF is the soft paywall that unlocks at Team — it is the format the compliance buyer needs to put the pack back into their requirements-management system. See Formats for a deep dive.

Storage and retention

Packs land in S3 at s3://{bucket}/evidence-packs/{release_id_or_set_hash}.zip. They live in S3 standard for 90 days, then transition to S3 Glacier Deep Archive, where they remain for the 10-year minimum the EU Product Liability Directive expects. The retention floor is configurable up to 25 years for industries with longer tails (medical devices, rail). See Archive lifecycle for the cost model and retrieval timing.

Tamper-evident hash chain

Every pack stores the SHA-256 hash of the previous pack for the same project and signs the combined manifest with an Ed25519 key Roboticks holds in AWS KMS. The chain is verifiable years later with rbtk evidence verify-chain. An auditor can prove that no historical pack was rewritten after the fact. See Hash chain.

Release-scoped vs ad-hoc

A pack is scoped either to a Release (the canonical form — pins commits across every linked repo and snapshots requirements) or to a branch + commit set for ad-hoc inspections. The Release form is what regulators expect; the ad-hoc form is for debugging, customer escalations, or sandbox runs. See Release scoping.

What this is not

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

Generate a pack

Dashboard button, API call, or rbtk test evidence-pack.

Read the manifest schema

Every field in evidence_pack.manifest.json explained.

Hand off to an auditor

Cover-letter template, read-only project access, the disclaimer.

Standards coverage

Which standards the pack is structured to satisfy.