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.
Generating an Evidence Pack
There are three entry points. They all enqueue the same builder pipeline and produce the same artefact in all three formats.From the dashboard
The path most users take.Open the release
Releases → choose a release → Overview. The release must be in state
verified or shipped (see Release scoping). A draft or verifying release cannot produce a pack.Click Generate Evidence Pack
A modal asks for the formats to render (PDF, ZIP, ReqIF — ReqIF is gated to Team and Enterprise) and any customization overrides (Enterprise only).
Watch the progress
The builder reports phase-by-phase progress via a websocket. Typical phases: snapshot requirements → collect JUnit XMLs → resolve MCAP references → assemble coverage → fetch SBOM → render PDF → assemble ZIP → sign manifest → upload to S3.
The release page now shows a green Pack generated badge with the SHA-256 of the manifest and a link to verify the hash chain.
From the API
For programmatic generation — release-gate scripts, custom CI jobs, integration with a release-train tool.job_id immediately. Poll GET /evidence-pack-jobs/{job_id} or subscribe to the websocket for progress. On success the body returns three signed download URLs (one per format) valid for 7 days.
From the CLI
The fastest path inside a CI pipeline or a developer shell../evidence-packs/. Add --no-wait to get just the job_id back.
See CLI commands for the full flag list.
The builder pipeline
The builder is a single AWS Lambda with a 15-minute budget. Packs that exceed the budget — typically very large repos with multi-gigabyte MCAP indexes — automatically fall back to an ECS Fargate task with a 6-hour budget. The fallback is transparent; the API and CLI behaviour does not change.Typical generation times
| Project size | Format | Time |
|---|---|---|
| Small (50 reqs, 200 tests, 1 GB MCAPs) | PDF only | 15–30 s |
| Small | All three | 30–60 s |
| Medium (500 reqs, 2 k tests, 20 GB MCAPs) | All three | 2–5 min |
| Large (5 k reqs, 20 k tests, 200 GB MCAPs) | All three | 8–15 min |
| Very large (Lambda → Fargate fallback) | All three | 20–90 min |
Errors and partial packs
A pack with any unresolved dependency (a missing MCAP, an unreachable connector, a corrupt SARIF) fails the job rather than producing a partial pack. The error is surfaced with the specific artefact at fault, and you can re-run after fixing the upstream. The platform never produces a silent best-effort pack. Auditors rely on completeness. For triage workflows where a partial view is useful, userbtk test evidence-pack --allow-partial. The resulting pack is marked partial: true in its manifest, refuses to enter the hash chain, and is watermarked NOT FOR AUDIT in the PDF.
Next steps
Formats deep dive
What the PDF, ZIP, and ReqIF deliverables look like.
Customise the pack
Cover pages, branding, custom sections. Enterprise.
Hand off to an auditor
Recommended cover letter and disclaimer.
Verify the chain
Prove a historical pack has not been altered.