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: 
evidence-pack-{release_id}.zip
├── README.md                          # Layout description, generator version
├── evidence_pack.manifest.json        # The machine-readable index
├── signature.sig                      # Ed25519 signature of the manifest
├── requirements/
│   ├── snapshot.reqif                 # ReqIF copy of the snapshotted requirements
│   ├── snapshot.json                  # JSON copy
│   └── derivations.json               # Standards → requirements derivation graph
├── tests/
│   ├── junit/*.xml                    # Every JUnit XML
│   ├── mcap-refs.json                 # Presigned URLs + SHA-256 for each MCAP
│   ├── logs/*.log                     # Runner and node logs
│   └── screenshots/                   # Optional, if --include-screenshots
├── coverage/
│   ├── gcov/                          # C++ coverage
│   ├── lcov/                          # Combined HTML report
│   └── coverage.py/                   # Python coverage
├── sbom/
│   ├── spdx.json                      # SPDX 2.3
│   └── cyclonedx.json                 # CycloneDX 1.5
├── static-analysis/
│   └── *.sarif                        # One file per scanner
└── traceability/
    └── matrix.csv                     # The matrix subset for this release
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:
Target toolTested withNotes
Polarion24.10Round-trips cleanly. Custom enums import as Polarion enums.
Jama2024.3Custom attributes preserved via the Jama ReqIF importer profile.
codeBeamer22Tested. Verification-Status mapping requires field setup.
DOORS Next7.0.3Tested. Use the DOORS Next Configuration Lead Tool import.
classic DOORS9.7Tested. Use DOORS Next bridge first.
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

RecipientRecommended format
External notified body or certification bodyPDF + ZIP
Internal QA gate reviewerPDF
Customer compliance team running Polarion or JamaReqIF
Customer auditor running their own toolingZIP
Future-you, post-incident, post-recall, mid-litigationAll three
When in doubt, hand over all three. They are bit-for-bit derived from the same source and the marginal storage cost is trivial.