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.

​
Pack Customization

The Free and Team default pack design is the recommendation for the vast majority of audit interactions. Customization is an Enterprise-tier capability for organisations whose auditors expect a specific layout, whose internal style guide constrains deliverables, or who hand packs through to downstream customers under their own brand.
Customization affects the PDF primarily. The ZIP and ReqIF formats remain raw and round-trippable. A customized PDF still satisfies the integrity model — the manifest and signature are unchanged.

​
What can be customised

ElementScope of change
Cover pageCustom HTML/CSS template; org logo, customer logo, project metadata, custom fields
Disclaimer pageAdd a customer-supplied disclaimer alongside the canonical Roboticks one; the canonical one is never removed
BrandingHeader / footer logos, colour palette overrides, font selection from a curated list
Custom sectionsInsert arbitrary HTML or Markdown sections between the standard sections
Section reorderingChange the order of standard sections
SuppressionSuppress optional appendices (screenshots, SBOM details, static-analysis full output) — never the manifest or the verification instructions
Page size and marginsA4 / US Letter / B5; configurable margins
LocaleDate format, decimal separator, table headers in customer’s locale (en, de, fr, ja, ko available)

​
What cannot be customised

The integrity-critical sections are immutable.
  • Manifest appendix — always printed verbatim.
  • Verification instructions — always printed; auditors must be able to verify.
  • Canonical Roboticks disclaimer — always present. You can add your own; you cannot remove ours.
  • Standards-derivation tables — content is dictated by your pinned standards, not customizable.
  • Test result tables — content reflects actual JUnit data.
This is by design: an auditor must be able to look at a Roboticks pack from any customer and find the same anchors. Customization is a presentation layer over invariant evidence.

​
Uploading a template

Templates live at the Project level (defaults flow from Organization).
1

Compose the template

Templates are a tarball with the following structure:
template.tar.gz
├── manifest.json          # Template version, schema, declared sections
├── cover.html.jinja       # Cover-page template
├── header.html.jinja      # Per-page header
├── footer.html.jinja      # Per-page footer
├── overrides.css          # CSS overrides applied after the default sheet
├── sections/
│   ├── 01-executive-summary.html.jinja   # Optional overrides
│   └── 99-custom-section.html.jinja      # New sections (filename ordering)
└── assets/
    ├── customer-logo.svg
    └── …
The Jinja templates have access to the full manifest model as a Python dict. The contract is documented at roboticks-sdk/schemas/template.context.json.
2

Validate locally

rbtk evidence template validate ./template.tar.gz
rbtk evidence template preview ./template.tar.gz \
  --release v1.4.0 \
  --out preview.pdf
The preview subcommand renders against a real release without uploading the template — useful for iterating on the design.
3

Upload

Project Settings → Evidence → Templates → Upload. Or:
rbtk evidence template upload ./template.tar.gz \
  --project acme-robotics/firmware
Uploaded templates are versioned; rolling back is a one-click revert.
4

Apply to a generation

On the Generate Evidence Pack modal, pick the uploaded template from the dropdown. From CLI:
rbtk test evidence-pack --release v1.4.0 --template customer-acme-v3

​
Co-branding workflows

A common Enterprise pattern: an OEM integrator generates packs for end-customer programs and hands them to the customer’s auditor under the customer’s brand. The recommended setup:
  • One base template at Organization level with your integrator branding.
  • Per-customer child templates at Project level that override the cover and header with the customer’s logo and palette.
  • A naming convention (customer-{name}-v{n}) so the pack-generation flow makes it obvious which template is selected.
The Roboticks footer marker is suppressible at Enterprise tier — replace it with your own attribution if your customer’s contract requires it.

​
Validation rules

Uploads are rejected if a template:
  • References missing assets.
  • Removes any of the immutable sections (manifest, verification instructions, canonical disclaimer).
  • Produces a PDF larger than 250 MB at preview (a defence against runaway template loops).
  • Contains executable content (no JavaScript; Jinja-only templating).
These constraints exist because a pack is signed evidence — the rendering process must be deterministic and the output must remain auditable.

​
Default appendix suppression

Even without a custom template, you can selectively suppress non-mandatory appendices at generation time: 
rbtk test evidence-pack --release v1.4.0 \
  --suppress screenshots,sbom-detail,sarif-full
AppendixDefaultSuppressibleNotes
Screenshotsincluded if capturedyesLarge; many auditors prefer the ZIP for these
SBOM detailfull tableyes (summary only)Suppresses per-component rows; keeps counts and CVE summary
SARIF full outputfull per-findingyes (severity-grouped summary only)Useful when the scanner emits thousands of low-noise findings
Manifest appendixfullnoRequired
Verification instructionsfullnoRequired
Coverage detailper-fileyes (project totals only)Some auditors want totals only

​
Next steps

Customer handoff

The cover-letter and access pattern for handing a pack to an auditor.

Compliance patterns

End-to-end workflows that show customization in context.