Skip to main content

​
Pack Formats

A single pack renders three ways. They are byte-different files; they describe the same release. Which one you hand to the recipient depends on what they ingest.

​
PDF — audit-ready

The PDF is the deliverable most external auditors and internal QA gate reviewers actually read. Structure (in the order it appears):
  1. Cover page — project name, release tag, generation timestamp, manifest SHA-256, generator version, Ed25519 signature thumbprint. Enterprise: customised per the customization options.
  2. Disclaimer — the canonical “audit-readiness, not certified” page. See Disclaimer.
  3. Table of contents — clickable in PDF readers that support it; the bookmarks index lists every requirement.
  4. Executive summary — counts: requirements pinned, requirements covered, requirements with gaps, total tests, pass rate, coverage percentages, SBOM component count, static-analysis finding counts by severity.
  5. Standards conformance section — for each pinned standard, the requirements that derive from it and their verification status. One subsection per standard.
  6. Requirements section — for each requirement: the immutable text, derivation source, confirming tests with pass/fail, MCAP links, deadline assertions, gap notes.
  7. Test results section — full JUnit roll-up with per-suite breakdowns and failure detail.
  8. Coverage section — gcov, lcov, and coverage.py outputs as styled tables; file-level and function-level.
  9. SBOM section — component table with name, version, license, supplier, and any known CVEs at generation time.
  10. Static-analysis findings — SARIF rendered as a per-tool, per-severity grouped table.
  11. Appendix A — manifest — the evidence_pack.manifest.json printed verbatim.
  12. Appendix B — verification instructions — exact commands an auditor runs to verify the chain and re-pull MCAPs from Glacier.
The PDF is generated with Chromium under a headless container. Page size defaults to A4; pass page_size: "letter" in the customization options for US auditors.
For human-scale review, the PDF is the right starting point. For machine-scale processing — automated ingestion into Polarion, programmatic CVE cross-checking — pair the PDF with the ZIP or ReqIF.

​
ZIP — every raw file

The ZIP contains every artefact at full fidelity. Auditors who run their own tooling against the raw evidence (rather than reading the PDF) prefer this format. Layout:
The ZIP is reproducible — the same release, regenerated, produces a ZIP with identical file contents (timestamps in the manifest are the only varying field, and they are deterministic from the release’s verification time).

​
ReqIF — round-trip into Polarion, Jama, codeBeamer, DOORS

ReqIF is the OMG-standardised XML format requirements-management systems use to exchange requirements with verification status. The Roboticks ReqIF export carries:
  • Every snapshotted requirement, with full attributes (id, title, text, type, ASIL/PL, derivation source, custom attributes).
  • A Verification-Status enumeration attribute on each requirement (covered, gap, acknowledged-gap).
  • A Verifying-Tests text attribute listing the confirming test names.
  • Per-requirement link attachments pointing at the JUnit XML and MCAP for the most recent confirming test run.
Compatibility:
ReqIF round-tripping is bidirectional. You can edit a requirement in Polarion and re-import it into Roboticks via the connector — the Roboticks copy is overwritten on next sync. See Connectors.

​
When to use which

When in doubt, hand over all three. They are bit-for-bit derived from the same source and the marginal storage cost is trivial.